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PREFACE 


This  document  is  the  first  of  three  volumes  which  make  up  the  assessment 
of  autonomy  for  the  DSCS  III  satellite  system.  Volume  I  is  an  overview  and 
summary  of  the  assessment.  Volume  II  is  a  functional  description  of  the 
existing  DSCS  III  satellite  system  and  an  assessment  of  its  current  autonomy. 
Volume  III  presents  options,  at  the  functional  level,  for  increasing  the 
autonomy  of  DSCS  III. 

The  DSCS  III  assessment  was  a  team  effort.  Authorship  of  specific 
sections  of  the  report  by  individual  JPL  contributors  is  acknowledged  in 
Volumes  II  and  III. 

The  results  reported  herein  are  based  almost  exclusively  on  a  JPL  review 
of  DSCS  III  documentation  provided  by  USAF  Space  Division.  This  documentation 
was  judged  generally  adequate  for  the  assessment.  However,  some  difficulty 
was  experienced  in  obtaining  the  needed  material  in  a  timely  manner,  and  in 
some  cases  it  was  necessary  to  make  assumptions  and/or  extrapolations  since 
needed  data  were  not  available.  Access  to  the  DSCS  III  library  at  Space 
Division  was  provided  for  team  members  near  the  end  of  the  assessment 
activity.  This  source  of  information  will  be  valuable  during  the  autonomous 
DSCS  III  design  phase. 

Because  the  critical  nature  of  the  first  DSCS  III  vehicle  requires 
intense  activity  by  General  Electric  Company  project  personnel,  JPL  was 
requested  to  avoid  contacting  these  personnel  for  information  or 
assistance  during  the  assessment  activity.  Several  contacts  were  made  with 
Aerospace  Corporation  personnel,  who  provided  assistance  to  the  JPL  team. 

DSCS  III  functions  were  classified  in  various  ways  as  part  of  the 
assessment.  Since  these  classifications  are  specified  throughout  the  volumes, 
a  ready  reference  is  provided  in  Appendix  B  which  defines  the  classification 
schemes. 
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SECTION  1 


PURPOSE  OF  THE  DSCS  III  ASSESSMENT 


The  nSCS  III  Assessment  was  performed  to: 

(1)  Assess  the  current  autonomy  level  of  DSCS  III  aqainst  recently 
developed  autonomy  qoals  (Reference  1), 

(2)  Assess  the  extent  to  which  DSCS  III  is  amenable  to  autonomy 
upqradinq , 

(3)  Suqqest  autonomy  addition  options  for  possible  consideration 
during  subsequent  DSCS  III  block  changes,  and  scope  the  complexity 
and  mass/power  implications  of  such  options,  and 

(4)  Prepare  for  the  autonomous  DSCS  III  design  task. 


SECTION  ? 


RACKfiROUNO 


2.1  PROGRAMMATIC  BACKGROUND 

During  the  summer  of  1980,  the  Space  Division  of  the  United 
States  Air  Force  initiated  planning  for  a  spacecraft  autonomy  program  intended 
to  provide  a  sound  technology  base  for  significantly  upgrading  the  autonomous 
capability  of  defense  satellites  by  the  end  of  the  decade.  The  broad  goal 
established  for  this  program  was  to  increase  mission  readiness  by  (listed  in 
order  of  priority  from  Reference  1): 

(1)  Enhancing  spacecraft  survivability  against  on-board 
failures. 

(2)  Enhancing  spacecraft  survivability  against  hostile  acts. 

(3)  Reducing  spacecraft  dependence  on  ground  stations,  thereby 
enhancing  the  capability  for  system  reconstitution  if  the 
ground  stations  were  disabled. 

(4)  Achieving  an  early  satellite  health  and  ephemeris 
maintenance  capability  by  Fiscal  Year  1987  (FY'R7),  with 
spacecraft  launched  after  this  date  capable  of  performing 
missions  for  unattended  periods  on  the  order  of  six  months. 

During  the  fall  of  1980,  the  Jet  Propulsion  Laboratory  (JPL) 
initiated  a  project  for  Space  Division  with  the  purpose  of  applying 
planetary  spacecraft  autonomy  technologies  and  procedures  to  military 
satellites.  This  report  is  an  output  of  Phase  1  (Project  Definition  Phase)  of 
the  JPL  Autonomous  Spacecraft  Project  (ASP). 

The  Task  Plan  for  all  of  Phase  I  is  contained  in  Reference  2. 
Relative  to  the  work  reported  herein,  the  Task  Plan  states: 

For  DSCS  III,  critique  the  existing  design  capability  for 

meeting  autonomous  operation  goals,  and  identify  how  additional 

autonomous  operation  features  could  be  included  within  the 

existing  system  design 

(1)  Without  additional  hardware,  and 

(2)  With  modest  iiardware  addition  or  changes. 

This  effort  is  referred  to  as  the  "DSCS  111  Assessment"  task. 

Future  Phase  I  efforts  will  include  a  DSCS  III  redesign  for 
autonomy  (at  the  system  and  subsystem  preliminary  requirements  level). 
Subsequent  phases  of  the  project  are  expected  to  proceed  through  autonomous 
subsystem  designs  and  demonstrations  and  a  system-level  demonstration. 
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THE  DSCS  III  SATELLITE 


2.? 


This  satellite  is  a  principal  element  of  the  Defense  Space 
Communications  System  (DSCS)  and  consists  of  continuously  operating,  superhiqh 
frequency  (SHF)  communications  satellites  in  synchronous,  equatorial  orbits, 
in  four  widely  separate  geographic  regions. 

The  mission  provides  satellite  communication  support  in  the 
1980s  to  the  Department  of  Defense  and  other  U.S.  Government  and  Allied  users 
under  unstressed  conditions,  and  provides  protected  support  to  selected  users 
who  have  been  assigned  missions  ''f  extreme  importance  in  the  defense  of  the 
U.S. A.  under  conditions  of  stress.  DSCS  III  must  maintain  critical  defense 
communications  in  a  nuclear  and  electronic  jamming  environment. 

The  first  DSCS  III  satellite  will  be  launched  in  1981  from  the 
Eastern  Test  Range  (ETR)  on  a  Titan  IIIC,  as  dual  launch  with  a  DSCS  II. 

Dry  mass  at  launch  £  860  kg 

Wet  mass  at  launch  ^  1137  kg 

Other  DSCS  satellites  will  be  launched  throughout  the  1980s.  A 
program  of  continuous  upgrading  of  functional  capability  by  block  procurement 
is  planned.  Autonomous  fault  protection  and  navigation  capabilities  are 
scheduled  to  be  introduced  in  the  late  1980s.  The  study  described  in  this 
report  assessed  the  design  of  the  first  satellite,  which  is  assumed  to  be 
representative  of  the  first  block  of  satellites.  No  attempt  was  made  to 
evaluate  planned  changes  for  future  blocks. 
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SECTION  3 


SUMMARY  OF  CONCLUSIONS  ANO  OBSERVATIONS 


The  conclusions  and  observations  are  sumnarized  here  and  are 
related  to  the  purposes  of  the  assessment.  Information  supporting  these 
conclusions  and  observations  is  summarized  in  Section  7.  Volumes  II  and  III 
contain  the  detailed  supporting  material. 


3.1  AUTONOMY  LEVELS  VS.  GOALS 

Levels  of  autonomy  were  defined  by  the  Goals  task  documented  in 
Reference  1,  and  are  reproduced  here  in  Appendix  A.  Levels  range  from  0 
to  10.  Conclusions/observations  relative  to  the  current  autonomy  of  OSCS  III 
vs.  the  goals  defined  in  Reference  1  include  the  following: 

(1)  The  existing  OSCS  111  functions  are  at  levels  of  autonomy 
ranging  from  0  to  5.  The  average  level  appears  to  be 
about  2  or  3.  This  means  that  there  is  a  high  level  of 
dependence  on  ground  operations  for  analysis,  planning,  and 
decision  making.  The  power  and  thermal  control  functions 
have  many  hard-wired,  autonomous  functions,  and  attitude 
control  has  considerable  autonomy  implemented  in  both 
software  and  hardware.  However,  spacecraft  resource 
management  and  health/welfare  maintenance  are  almost 
entirely  ground  directed.  Stationkeeping  is  completely 
directed  by  the  ground. 

(2)  A  primary  goal  expressed  in  Reference  1  is  for  the 
spacecraft  to  operate  for  60  days  with  nominal  performance 
and  for  6  months  with  acceptable  perfprmance,  without 
ground  intervention.  A  spacecraft  autonomy  level  of  about 
5  is  required  to  meet  this  goal.  A  Level  5  spacecraft  (see 
Appendix  A)  is  capable  of  executing  a  prespecified  program 
of  events  and  is  also  autonomously  fault  tolerant. 

(3)  The  goal  of  60  days  nominal  performance  and  6  months 
acceptably  degraded  performance  levies  basically  the  same 
requirements  on  autonomy.  This  means  that  the  sensing  and 
computing  additions  required  to  make  the  spacecraft  fully 
autonomous  for  60  days  should  also  enable  6  months 
operation  without  ground  intervention. 
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(4)  The  autonomous  DSCS  III  assessment  philosophy  assumes  that 
the  requirement  for  6-month  performance  without  ground 
intervention  arises  from  a  high-level -of-confl i ct 
situation.  It  has  been  assumed  that  under  other  conditions 
the  ground  will  be  able  to  periodically  update  the  initial 
orbital  state  from  which  the  spacecraft  will  have  to 
operate  independently.  If  this  assumption  is  not  valid, 
the  spacecraft  autonomy  level  may  have  to  be  increased 
beyond  5  (see  Appendix  A)  to  somehow  provide  its  own 
initial  state. 

(5)  On-board  redundancy  management  is  required  for  a  high 
probability  of  meeting  the  60-day /6-month  requirement, 
particularly  if  hostile  threats  to  the  spacecraft  are 
considered. 

(6)  Autonomous  stationkeeping  is  also  required,  even  for  60 
days  performance,  since  east-west  stationkeeping  maneuvers 
are  required  more  frequently  to  meet  the  +^0.1° 
stationkeeping  requirements.  The  maneuvers  could 
occasionally  occur  as  frequently  as  every  few  days 
(depending  upon  station  location  and  sun-moon  perturbation 
phasing) . 


3.2  AUTONOMOUS  CAPABILITIES  OF  EXISTING  DESIGN 

Volume  II  provides  a  functional  description  of  the  existing  DSCS 
III  system.  Some  observations  can  be  made  about  the  current  autonomy  and 
its  capacity  for  being  increased  by  on-board  software  changes  only. 

(1)  The  DSCS  III  system  currently  has  a  good  deal  of  autonomy 
in  its  power,  thermal  control,  attitude  control,  and 
telecommunications  service  functions. 

(2)  The  DSCS  III  system  has  generally  adequate  data,  sensing, 
redundancy,  and  cross-strapping  for  integrity  maintenance 
(health  and  welfare),  but  almost  all  analyses  and 
direction  of  redundancy  management  are  done  by  the  ground. 

(3)  No  present  DSCS  III  capability  exists  for  autonomous 
stationkeeping,  or  ephemeris  maintenance. 

(4)  One  computer  system  (primarily  performing  attitude  control 
functions)  is  presently  on  board.  In-flight  or  preflight 
reprogramming  to  increase  autonomy  is  feasible,  but  its 
possibilities  appear  very  limited.  Some  changes  could  be 
readily  introduced  to  provide  flexibility  of  response  to 
situations  which  now  result  in  survival  modes.  Other 
changes  could  improve  operability  of  the  spacecraft  by  the 
ground  and/or  provide  some  additional  measures  of  fault 
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protection.  The  overall  capability  of  the  DSCS  111 
spacecraft  to  be  made  autonomous,  in  its  current 
conf iquration,  appears  to  be  considerably  less  than  that  of 
the  Voyager  or  Viking  planetary  exploration  spacecraft. 

(5)  In  its  current  configuration  the  nSCS  111  spacecraft  cannot 
be  made  free  of  ground  intervention  for  even  60  days. 


3.3  OPTIONS  FOR  INCREASING  AUTONOMY 

A  range  of  options  was  developed  during  the  assessment.  The 
options  are  documented  in  Volume  III.  They  range  from  modest  computer  and 
sensor  additions  (less  than  5%  total  mass/power  impacts)  to  additions  which 
could  be  equivalent  to  a  redesign  of  the  spacecraft.  The  options  could  be 
implemented  in  a  phased  program,  examples  of  which  are  presented  later  in 
Volume  I.  Some  observations  concerning  the  options  include: 

(1)  The  DSCS  III  spacecraft  can  be  made  fully  autonomous  for  6 
months  by  adding  features  to  create  an  autonomy  level  of  5. 
This  will  require  additions  or  redesign  which  do  not  meet 
the  assessment's  definition  of  "modest"  changes. 

(2)  A  number  of  options  are  available  for  creating  partial  or 
phased  autonomy  with  modest  changes  to  hardware  and 
software.  These  are  described  in  Section  7,  and,  in  more 
detail ,  in  Volume  III. 

(3)  For  functions  which  require  large  numbers  of  sequential 
ground  commands,  on-board  sequencing  can  be  a  substantial 
contributor  to  6  months  operation  without  ground 
intervention.  Sequencing  is  suitable  for  events  which  can 
be  predicted  and  for  which  no  on-board  decisions  are 
required  (e.g.,  some  routine  service  and  health  maintenance 
functions).  For  the  remaining  functions  on-board  sensing, 
analysis,  decision  making,  direction,  control,  and  action 
are  required. 

(4)  The  existing  ACS  computer  has  some  capability  for  add-on  to 
make  additional  functions  autonomous  [up  to  18k  of  16-bit 
words  random-access  memory  (RAM)  or  read-only  memory  (ROM) 
and  49*  of  central  processing  unit  (CPU)  time].  Fully 
exploiting  this  capacity  will  have  costs  in  terms  of  mass, 
power,  and  design  and  operation  inefficiencies.  If  this 
option  were  pursued,  further  study  would  be  required  to 
determine  the  exact  impacts. 

(5)  Autonomous  redundancy  management  for  integrity  maintenance 
will  require  a  sizeable  addition  to  on-board  computing 
capacity  (from  8k  to  32k  8-bit  words).  Additional 
sensors  to  acquire  direct  health  measurements  may  also  be 
requi  red. 
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(6)  Addition  of  autonomous  stationkeeping  will  require  new 
location  sensors  as  well  as  added  on-board  computer 
capability  (between  16k  16-bit  and  32k  32-bit  words  of 
memory).  Addition  of  this  function  will  at  the  same  time 
provide  most  of  the  capability  for  on-board  propulsion 
resource  management  and  autonomous  attitude  control. 
Addition  of  the  improved  sensors  will  improve  spacecraft 
operability,  even  if  the  autonomous  navigation  computing 
function  is  added  later. 

(7)  Two  modest-to-extensive  additions  (plus  their  executive 
control)  are  required:  an  on-board  redundancy  management 
function  such  as  described  in  Section  4  of  Volume  III,  and 
an  autonomous  stationkeeping  function  as  described  in 
Section  2  of  Volume  III.  The  added  combination  of  these 
functions,  plus  the  expansion  of  the  ACS  computer  capacity 
and  the  addition  of  executive  control  functions,  is 
equivalent  in  scope  to  a  system  redesign. 

(8)  Nonvolatile,  long-term  data  storage  will  be  required  for 
fault  protection  audit  trail  storage,  program  storage,  and 
storage  of  parameters  for  autonomous  stationkeepinq.  Up  to 
10^  bits  of  mass  storage  could  be  required. 

(9)  Very  preliminary  estimates  of  mass  and  power  impacts  on  the 
spacecraft  have  been  made.  These  are  not  based  on  a 
system-level  design.  (The  design  task  is  to  follow  the 
assessment.)  The  estimate  does  not  include  possible 
requirements  for  structural  changes,  additional 
health/welfare  state  sensors,  additional  propulsion 
capability,  or  contingencies.  For  a  fully  autonomous. 

Level  5  spacecraft,  estimates  of  mass  increases  range  from 
55  to  131  kg.  Estimates  of  the  required  power  increases 
range  from  47  to  127  W.  ["Modest"  mass  increases  are 
defined  to  be  about  43  kg  (5%)  of  spacecraft  dry  mass. 
"Modest"  power  increases  are  defined  to  be  about  45  W 

(5%)  of  spacecraft  power.]  Telecommunication  autonomy  may 
be  necessary,  and  could  add  as  much  as  5%  additional  mass 
and  power. 

(10)  Very  preliminary  estimates  of  autonomous  spacecraft 
complexity  in  terms  of  active  on-board  memory  have  been 
made.  These  are  not  based  on  a  system-level  design.  A 
Level  5  spacecraft  may  have  as  many  as  10  active  computer 
processors  on-board,  containing  between  784k  and  2032k  bits 
of  information.  Nonvolatile,  bulk  memory  and  standby 
processors  are  not  included.  By  this  measure  of 
complexity,  a  Level  5  spacecraft  may  be  equivalent  to  JPL's 
Galileo  spacecraft  in  terms  of  systems  design  and 
validation  difficulty. 

(11)  Ground  system  impacts  of  spacecraft  autonomy  will  depend  on 
the  philosophy  with  which  the  autonomy  is  introduced  and 
used.  Spacecraft  autonomy  creates  increased  requirements 
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for  validation  and  testing  to  create  confidence  in  the 
autonomous  features.  Spacecraft  control  ground  operations 
could  conceivably  be  reduced  to  zero  either  by  creating  and 
fully  validating  a  Level  5  spacecraft,  or  by  shifting  some 
spacecraft  control  functions  to  payload  control.  The 
latter  option  may  cause  unacceptable  impacts  on  payload 
control  operations. 

(12)  A  phased  program  of  autonomy  increments  can  mitigate 

mass/power  and  operations  impacts  by  introducing  autonomy 
changes  in  conjunction  with  other  planned  changes  to  the 
DSCS  III  payload  and  spacecraft.  For  an  on-going  program, 
such  as  DSCS  III,  this  is  probably  the  preferred  approach. 
If  the  autonomy  additions  are  compared  with  planned  changes 
to  DSCS  III  in  future  block  procurements,  the  impacts  of 
autonomy  additions  are  relatively  modest. 


3.4  CONSIDERATIONS  FOR  DESIGN  TASK 

The  task  of  providing  a  conceptual  design  for  an  autonomous 
DSCS  III  will  be  conducted,  building  on  the  results  of  this  assessment. 

Several  issues  relevant  to  the  design  task  were  identified  during  the 
assessment.  These  include  the  following: 

(1)  A  top-down  design  approach  is  necessary,  even  if  autonomous 
capability  is  added  incrementally,  to  make  trade-offs  and 
ensure  compatibility  of  time-phased  additions. 

(2)  The  biggest  challenge  in  implementing  DSCS  III  full 
autonomy  is  likely  to  be  in  the  system  and  software  design 
and  validation  areas,  rather  than  in  hardware  development 
and  implementation. 

(3)  Five  major  system  trade-offs  must  be  addressed  during  the 
autonomous  DSCS  III  design  phase: 

(a)  Phasing  of  additions  vs.  redesign. 

(b)  Distributed  vs.  central  computing. 

(c)  Additional  direct  health  sensors  vs.  increased  health 
inference  logic. 

(d)  Level  of  ground  dependence  vs.  spacecraft  autonomy 
1 evel . 

(e)  Fault  detection  and  correction  strategy. 

(4)  Ground  costs  vs.  spacecraft  costs  must  be  considered  in 
selecting  functions  to  be  made  autonomous  and  in  selecting 
levels  of  autonomy  for  each  function. 
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(5)  The  impact  on  the  ground  operations  of  adding  autonomy  to 

the  nsCS  III  satellite  will  depend  on  trade-offs  between: 

(a)  The  level  of  preflight  validation,  on-orbit  checkout, 
and  in-flight  self-validation  of  the  autonomy 
features  vs.  the  level  of  ground  monitoring  of  the 
autonomous  functions  in-flight, 

(b)  The  degree  to  which  Category  II  (lifetime 
extending/operability  improving)  functions  are  made 
autonomous. 

(c)  The  degree  to  which  the  payload  control  function  can 
assume  monitoring  of  spacecraft  functions  during  high 
levels  of  conflict. 
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SECTION  4 


CONSTRAI NTS 


4.1  PAYLOAD  CONSIDERATIONS 

The  assessment  was  restricted  to  nonpayload  functions,  except 
where  overlaps  between  payload  and  nonpayload  functions  occurred. 

Nonpayload  functions  are  those  provided  by  the  spacecraft,  and  its  ground 
support  system,  to  the  payload,  i.e.,  a  stable  platform,  power,  thermal 
control,  and  an  alternate  communication  channel.  Requirements  placed  on  the 
spacecraft  by  the  payload  were  identified  and  considered  in  the  assessment, 
and  payload/spacecraft  interfaces  were  defined.  However,  no  consideration  was 
given  to  automating  payload  functions. 


4.2  EXTERNAL  THREAT  CONSIDERATIONS 

Space  Division  and  JPL  agreed  that  it  was  not  necessary  to 
provide  the  capability  for  the  spacecraft  to  autonomously  avoid  external 
threats.  The  assessment  did,  however,  consider  recovery  from  failure  modes 
which  could  have  been  caused  by  several  factors,  including  threat  effects. 


4.3  CONSIDERATION  OF  DESIGN  FEATURES  NOT  RELATED  TO  AUTONOMY 

The  assessment  evaluated  the  ability  of  the  current  DSCS  III 
design  to  be  made  more  autonomous,  and  several  options  addressed  specifically 
to  DSCS  III  autonomy  have  been  developed.  The  assessment  was  not  to  consider 
performance  improvement  options  such  as  reductions  in  mass,  improvements  in 
pointing  accuracy,  or  extensions  of  design  lifetime.  However,  autonomy 
additions  could  be  expected  to  improve  reliability  and  extend  lifetime. 
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SECTION  5 


ASSUMPTIONS 


5.1  USE  OF  GOALS  DOCUMENT 

The  generic  goals  presented  in  the  Goals  Document  (Reference  1) 
were  assumed  to  be  applicable  to  an  autonomous  DSCS  III.  In  fact,  the 
assessment  will  be  used  to  test  the  utility  of  these  goals  as  part  of  the 
forthcoming  Design  Methodology  task  (see  Reference  2).  In  addition,  the 
existing  DSCS  III  and  the  options  for  its  increased  autonomy  were  evaluated 
against  the  levels  of  autonomy  given  in  the  Goals  Document. 


5.2  ASSESSMENT  PRIORITIES 

All  the  DSCS  III  functions  were  addressed  in  the  assessment. 
However,  when  time  and/or  staffing  constraints  limited  the  scope  or  depth  of 
the  assessment,  the  following  priorities  were  used: 

(1)  On-station  functions  over  initialization  (postlaunch) 
functions. 

(2)  Normal  modes  of  operation  over  abnormal  modes.  For 
example,  options  for  maintaining  performance  when  all 
spares  were  depleted  were  not  investigated  as  deeply  as 
simple  redundancy  management. 


SECTION  6 


APPROACH 


6.1  STRUCTURE  OF  ASSESSMENT 


6.1.1  Assessment  Process* 

Figure  6-1  is  a  flow  diagram  of  the  assessment  process.  First, 
a  structure,  identified  as  (1)  in  the  figure,  was  developed  for  categorizing 
the  functions  of  DSCS  III.  Roth  requirements  (2)  and  capabilities  (3)  of  the 
existing  DSCS  III  were  identified  and  were  documented  in  this  structure.  The 
generic  autonomy  goals  (4)  from  an  early  version  of  the  Goals  Document 
(Reference  1)  were  overlaid  on  the  existing  DSCS  III  requirements  to  produce 
requirements  (5)  for  an  autonomous  DSCS  III.  The  capabilities  of  the  existing 
DSCS  III  were  evaluated  and  concepts  were  formulated  for  increasing  its 
autonomy.  These  concepts  are  the  autonomous  options  (6).  The  options  (6) 
were  compared  with  the  requirements  (5)  and  were  classified  (7)  by  level  of 
autonomy  and  difficulty  of  implementation.  Recommendations  (8)  were  made  for 
revisions  to  both  goals  and  level -of-autonomy  definitions  in  the  final  Goals 
Document.  The  results  of  this  process  are  documented  in  this  report  (9). 


6.1.2  Functional  Structure* 

Information  on  DSCS  III  was  available  on  a  subsystem  basis.  The 
existing  DSCS  III  subsystems  are  shown  with  relation  to  each  other  in  Figure 
6-2.  However,  in  order  to  assess  DSCS  Ill's  capabilities  for  autonomy,  it  was 
necessary  to  describe  its  capabilities  in  a  functional  manner.  The  structure 
selected  to  express  this  functional  description  is  used  both  for  the  primary 
functions  required  for  the  spacecraft  to  operate  sati sfacluri ly  and  for  the 
primary  functions  required  for  it  to  operate  autonomously.  Spacecraft 
functions  are  grouped  into  three  categories: 

(1)  Provide  services  to  payload. 

(2)  Manage  spacecraft  resources. 

(3)  Maintain  integrity  of  spacecraft. 

Services  are  those  functions  which  the  spacecraft  provides  to 
make  it  possible  for  the  payload  to  operate  satisfactorily,  viz,  a  stable 
platform,  power,  thermal  control,  and  alternate  S-band  or  X-band  telemetry  and 
command  channels. 


*The  assessment  structure  and  process  are  based  on  concepts  developed  by  R.  V. 
Morris  of  JPL. 
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Figure  6-1.  Autonomy  Assessment  Work  Plan 


TO  COMM 
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Resources  are  those  limited  expendables  which  must  be  manaqed 
for  the  spacecraft  to  survive  and  perform  as  required,  viz,  power  and 
propulsion  resources. 

Integrity  refers  both  to  health  and  welfare  and  to  protection 
of  the  spacecraft  from  failures. 

In  order  to  analyze  an  autonomous  operation,  it  is  convenient  to 
subdivide  it  into  the  functional  classes  of  activity: 

(1)  Sense  (or  perceive  a  need). 

(2)  Direct  (and  control  an  action  plan). 

(3)  Act  (execute  the  plan). 

These  functions  are,  of  course,  required  for  the  spacecraft  to 
operate  whether  they  are  done  autonomously  or  with  ground  intervention. 
However,  an  autonomous  activity  must  involve  all  three  of  these  functions. 

Both  categories  (spacecraft  and  autonomy)  were  used  to  classify 
each  DSCS  III  function.  Together,  they  form  a  functional  structure 
illustrated  as  a  matrix  in  Table  6-1. 


Table  6-1.  Autonomous  System  Functional  Structure 


FUNCTIONS 

SENSE 

DIRECT/CONTROL 

ACT 

PROVIDE  SERVICES  TO  PAYLOAD 

MANAGE  SPACECRAFT  RESOURCES 

MAINTAIN  INTEGRITY  OF  SPACECRAR 
SYSTEM 

Each  of  the  horizontal  autonomy  functions  (sense, 
direct/control,  act)  must  be  performed  to  carry  out  the  vertical  spacecraft 
functions.  Here,  sense  means  the  act  of  obtaining  the  information  needed  to 
carry  out  the  vertical  functions.  For  example,  the  spacecraft  must  sense  its 
orientation  in  space  to  provide  accurate  pointing  for  the  payload.  It  muct 
sense  the  hydrazine  mass  remaining  in  the  propellant  tanks  to  manage  the  rate 
of  expenditure  of  the  hydrazine  resource  resulting  from  thruster  firings.  It 
must  sense  faults  or  failures  of  the  spacecraft  hardware  and  software  to 
maintain  the  integrity  (health  and  welfare)  of  the  system.  The  sensing 
function  also  includes  the  analysis  required  to  interpret  the  data  obtained  by 
the  sensors.  This  may  include  analysis  of  data  from  a  combination  of  sensors. 
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or  recognizing  patterns  of  measurements  which  indicate  (for  example)  a 
failure. 


The  sensed  information  is  then  used  to  formulate  a  plan  of 
action  (direct)  and  to  issue  the  instructions  control  which  will  cause  the 
plan  to  be  carried  out  (act).  Thus,  a  maneuver  sequence  is  developed  in 
response  to  a  sensed  degradation  in  the  orbit  position  of  the  spacecraft. 

This  sequence  directs  the  electronics  control  1 ing  the  thruster  firings  (among 
other  things).  The  actual  firing  of  the  thruster  is  the  action  taken. 

For  the  DSCS  III  Assessment  this  matrix  structure  was 
reformatted  as  a  functional  hierarchy,  as  illustrated  in  Figure  6-3.  This 
structure  forms  the  basis  for  this  report  and  is  discussed  in  the  next 
section.  The  functional  hierarchy  was  used  to  structure  both  the  existing 
nsCS  III  and  the  autonomy  options.  It  therefore  served  to: 

(1)  Match  requirements  and  functions  at  the  appropriate 
1 evels. 

(2)  Identify  areas  of  overlap  between  functions. 

(3)  Identify  gaps  in  the  existing  DSCS  Ill's  capability  to 
sense,  direct,  control,  or  act  to  carry  out  its  functions 
autonomously. 

(4)  Provide  a  common  reference  for  work  done  by  the  various 
elements  of  the  study  team. 

(5)  Provide  a  basis  for  an  autonomous  DSCS  III  design. 


6.1.3  Assessment  Functional  Classification 

The  DSCS  III  functions  were  classified  in  three  ways:  by  level 
of  autonomy,  by  importance,  and  by  difficulty  of  implementation. 


6. 1.3.1  Levels  of  Autonomy.  The  levels  specified  in  the  Coals  Document 

(Reference  1)  were  applied  to  both  the  existing  DSCS  III  and  the  autonomy 
options.  These  levels  (from  0  to  10)  are  reproduced  in  Appendix  A. 


6. 1.3. 2  Importance.  The  primary  requirement  which  drives  the  DSCS  III 

autonomy  is  for  the  spacecraft  to  operate  with  reduced  ground  intervention. 

As  stated  in  the  Goals  Document: 

The  autonomous  spacecraft  shall  be  capable  of  successfully 
performing  the  mission  function  for  an  extended  period  of  time 
without  ground  support  at  a  specified  level  of  conflict. 
Specifically: 

(1)  Autonomous  spacecraft  shall  operate  without  performance 

degradation  for  up  to  60  days  from  the  last  initialization 
update. 


DSCS  III 
SYSTEM 
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Figure  6-3.  DSCS  III  Functional  Hierarchy 


(2)  Autonomous  spacecraft  shall  operate  for  up  to  6  months  from 
the  last  initial ization  update.  They  shall  do  so  within 
acceptable  performance  degradation  limits  for 
mission-prioritized  functions  as  defined  by  each  mission. 

These  requirements  were  used  as  the  basis  for  prioritization  of 
autonomous  operation  as  follows: 

(1)  Category  I:  Functions  which  must  be  performed  autonomously 
for  the  spacecraft  to  meet  the  6f)-day/fi-month  requirement. 

(2)  Category  II:  Functions  which  must  be  performed 
autonomously  for  lifetime  protection  (battery  conditioning, 
etc.)  or  which,  if  performed  autonomously,  would  increase 
the  operability  or  operational  flexibility  of  the 
spacecraft. 

(3)  Category  III:  Functions  not  requiring  autonomy. 


6. 1.3. 3  Difficulty  of  Implementation.  There  are  three  modes  by  which 

the  DSCS  III  satellite  system  can  be  made  more  autonomous:  Software,  Add-on, 
and  Redesign.  The  first  is  to  utilize  the  existing  hardware  capabilities  of 
the  system  and  make  software  changes  to  increase  autonomy.  The  attitude 
control  subsystem  includes  a  computer  which  is  capable  of  being  reprogrammed 
to  increase  the  spacecraft  autonomy  (see  Section  2.2  and  4.2  of  Volume  III). 
This  mode  will  be  referred  to  as  the  Software  mode.  It  will  produce  the  least 
expensive  modification  to  DSCS  III  but  is  very  restricted  in  its  ability  to 
add  autonomous  capability  to  the  system.  The  Add-on  mode  adds  hardware  as 
well  as  software  to  the  spacecraft  but  avoids  making  major  design  changes. 

The  third  mode.  Redesign,  allows  consideration  of  redesigning  the  DSCS  III 
system  to  increase  its  capabilities  for  autonomy.  The  Add-on  and  Redesign 
modes  have  gradations  of  difficulty.  This  assessment  classified  hardware 
modifications  as  "modest"  or  "extensive." 

For  the  purposes  of  the  DSCS  III  Assessment  task,  "modest 
hardware"  modifications  may  consist  of  the  following: 

(1)  New  hardware  introduced  into  the  spacecraft  system  to 
perform  autonomy  functions,  and/or 

(2)  Modifications  of  hardware  already  existing  in  the 
spacecraft  system. 

In  order  to  be  classified  as  "modest,"  arbitrary  constraints 

were  defined; 

(1)  The  effects  of  added  hardware  would  not  allow  the  mass  or 
power  of  the  spacecraft  to  grow  more  than  5%,  or  the  mass 
or  power  of  an  individual  subsystem  to  grow  more  than  20%. 
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(2)  No  more  than  15%  of  the  spacecraft  system's  electrical 
interfaces  would  be  impacted. 

(3)  If  hardware  is  modified,  the  major  function  of  that 
hardware  would  not  be  changed. 

(4)  No  more  than  20%  addition  of  piece  parts  would  be  allowed, 
and  no  more  than  20%  new  electrical  interfaces  would  be 

a  1 1  owed . 

Any  changes  with  scope  larger  than  a  "modest"  modification  are 
referred  to  as  "extensive."  Throughout  the  document  the  following 
designations  are  used  to  classify  functions  by  their  difficulty  of 
impl ementation ; 


Class  A  =  Software  changes  only 
Class  B  =  Modest  additions 
Class  C  =  Extensive  additions 
Class  D  =  Redesign 


6.2  STRUCTURE  AND  USE  OF  THE  DOCUMENT 


6.2.1  Structure 

Volumes  II  and  III  of  this  assessment  report  are  structured  in 
accordance  with  the  functional  hierarchy,  Figure  6-3.  Volume  II  contains  the 
detailed  description  of  the  existing  DSCS  HI  functions,  and  Volume  III 
contains  the  corresponding  details  of  the  options  for  increasing  autonomy. 
Detailed  functional  block  diagrams  are  included  in  Volume  II.  Each  element  in 
these  block  diagrams  corresponds  to  a  paragraph  in  Volumes  II  and  III. 
Furthermore,  each  paragraph  in  Volume  II  has  a  corresponding  paragraph  in 
Volume  III  which  is  identified  by  the  same  decimal  number.  For  example. 
Paragraph  2. 2. 1.4  in  Volume  II  describes  the  Reacguire  References  function  as 
it  now  is  performed.  It  is  partially  autonomous.  Paragraph  2. 2. 1.4  in  Volume 
III  describes  how  the  Reacquire  References  function  could  be  made  fully 
autonomous.  Requirements  on  each  function  are  included  in  Volume  II  at  the 
beginning  of  that  function's  description.  Volume  II  includes  an  overview  of 
the  DSCS  III  mission  and  system,  and  its  requirements. 


6.2.2  Use 

The  structure  of  the  document  lends  itself  to  use  by  people 
interested  in  particular  functional  aspects  of  the  DSCS  III  system.  The 
function  of  interest  can  be  identified  either  from  the  table  of  contents  or 
from  the  functional  hierarchy  diagrams.  DSCS  III  specialists,  for  example, 
can  evaluate  the  accuracy  of  a  DSCS  III  functional  description  in  Volume  II, 
and  then  can  identify  the  specific  autonomy  option  suggested  for  that  function 
in  Volume  III.  Volume  I  was  prepared  for  readers  interested  in  a  broader 
perspective  of  the  assessment,  and  also  contains  necessary  background  and 
definitions  for  users  of  Volume  II  and  III. 
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SECTION  7 


ASSESSMENT  SUMMARY 


This  section  contains: 

(1)  A  summary  characterization  of  the  current  DSCS  Ill's 
autonomy  status, 

(2)  A  summary  discussion  of  options  for  increasing  the  autonomy 
of  nSCS  HI,  and 

(3)  Some  preliminary  estimates  of  the  direct  mass,  power,  and 
complexity  impacts  on  DSCS  HI  which  would  accrue  if  one  of 
the  possible  autonomy-incrementing  strategies  were 
implemented. 

7.1  SUMMARY  OF  AUTONOMY  LEVELS  OF  THE  EXISTING  DSCS  HI  SPACECRAFT 

FUNCTIONS 

Figure  7-1  summarizes  the  autonomy  levels  of  the  existing  DSCS 
III  functions.  As  before,  the  functions  are  classified  as  Services, 

Resources,  and  Integrity,  and  by  Category  (I,  II,  IH).  The  length  of  each 
bar  in  the  figure  represents  the  number  of  functions  at  that  level  of 
autonomy.  (Refer  to  Appendix  A  for  autonomy  level  definitions.)  Category  I, 
II,  and  IH  functions  are  designated  separately. 

Figure  7-1  illustrates  that  the  Services  functions  tend  to 
cluster  around  Level  3,  the  Resources  functions  around  Level  1  or  2,  and  the 
Integrity  functions  around  Level  2.  Services  functions,  except  for 
stationkeeping,  are  at  higher  levels  because: 

(1)  The  power  and  thermal  control  functions  have  a  good  deal  of 
hard-wired,  autonomous  functions,  and 

(2)  The  attitude  control  function  has  considerable  autonomy 
implemented  in  both  software  and  hardware,  whereas 

(3)  Resources  and  Integrity  functions  are  almost  entirely 
ground  directed,  and 

(4)  Stationkeeping  is  entirely  ground  directed. 

Figure  7-1  also  illustrates  that  the  majority  of  functions  are 
Category  I,  that  is,  they  must  be  autonomous  for  the  spacecraft  to  operate  for 
6  months  without  ground  intervention.  In  order  to  meet  the  regui rements,  the 
majority  of  Category  I  functions  will  need  to  be  raised  to  about  Level  5. 

Table  7-1  lists  the  functions  which  were  used  to  make  up  Figure 
7-1,  by  autonomy  level  and  category.  The  paragraph  numbers  in  Table  7-1  refer 
to  Volumes  II  and  IH.  Volume  H  contains  a  detailed  description  of  the 
current  functions.  Volume  HI  gives  details  on  options  for  increasing  the 
autonomy  of  each  function. 


Table  7-1.  List  of  Current  DSCS  III  Functions  by  Autonomy  Level  and  Category: 
(a)  Services,  (b)  Resources,  (c)  Integrity 


DISTRIIUTE  INSTRUCTKDNS  (TT  &  C) 
WARM  UP  CATALYST  KD  (ACS) 


ORIENT  SOLAR  ARRAY  (ACS) 


(c)  <NT€GR/TY 


BATTERY  OPERATIONS  INTEGRITY  (EPOS) 


4. 2. 2. 4  REG  ELECTRONKS/QUAD  REUV  FAILURE  (EFDS) 

4.3. 2. 3  NUCLEAR  EVENT  (ACS) 

4.3.2. 4  PROTECT  EARTH  SENSOR  (ACS) 


7.2 


EXAMPLE  OF  A  PHASED  PROGRAM  FOR  CREATING  A  LEVEL  5  AUTONOMOUS 
DSCS  III  SPACECRAFT 


Table  7-2  summarizes  the  options  for  adding  autonomy  to  DSCS 
III.  All  of  the  Category  I  functions  through  Class  C*  must  be  added  to  make 
the  DSCS  III  spacecraft  system  performance  acceptable  while  independent  of  the 
ground  for  6  months.  The  arrows  in  Table  7-2  indicate  that  the  function  may 
be  partially  performed  at  the  lower  class  (where  the  arrow  starts),  but  will 
probably  require  the  higher  class  of  modification  (where  the  arrow  ends)  to  be 
completely  autonomous.  Table  7-2  illustrates  that  extensive  add-ons  or 
redesign  will  be  necessary  to  create  a  fully  autonomous  spacecraft. 

Functions  which  must  be  made  more  autonomous  are  of  all  three  types:  provide 
services,  manage  resources,  and  maintain  integrity. 


Table  7-2.  Classification  of  Options  for  Increasing  DSCS  III  Autonomy 


CLASS 

CATEGORY^^.^^^ 

A 

SOFTWARE 

MODE 

6 

MODEST 

ADD-ON 

C 

EXTENSIVE 

ADD-ON 

D 

REDESIGN 

•  SOME  ATTITUDE  CONTROL 

•  BATTERY  RESOURCE 

•  POWER  load  ANOMALIES 

o 

1 

-  VALIDATE  EARTH  LOSS 

-  REACQUIRE  EARTH 

•  FULL  AUTONOMY  OF 
ATTITUDE  CONTROL  SERVICE" 

^  SELECTION 
■^AUTONOMOUS 

REQUIRED  FOR 

60-do  y/6  -  mon » h 

autonomy 

-  REACTION  WHEEL 

FAILURE  DETECTION/ 
SHUTDOWN 

FUNCTIONS 
•  SPACECRAFT 

STATIONKEEPING 

-  NONSTANDARD 
MOMENTUM  DUMPING 

MANAGEMENT 

•  AUTONOMOUS  ATTiTUDE 
CONTROL  FOR  MANEUVERS 

II 

LIFETIME  PROTECTION 
OF  INCREASED 
OPERABILITY 

•  SELECT  BATTERY  CHARGING 
PARAMETERS 

•  propulsion  RESOURCE 
MANAGEMENT 

•  TFI  FrOAAMUNlCATION^ 

INTEGRITY  MAINTENANCE 

III 

AUTONOMY  NOT 
REQUIRED 

•  ALTERNATE  PAYLOAD 
COMMAND  GENERATION 

•  PAYLOAD  ANTENNA 
POINTING 

•  BATTERY  RECONDITIONING 

•  ANTENNA  POINTING 

PREDICTS 

ARROWS  INDICATE  THAT  THE  FUNCTION  MAY  BE  PARTIALLY 
PERFORMED  AT  THE  LOWER  CLASS  BUT  WILL  PROBABLY 
REQUIRE  THE  HIGHER  CLASS  OF  MODIFICATION  TO  BE 
COMPLETELY  AUTONOMOUS. 


Figure  7-2  is  a  flow  diagram  showing  three  examples  of 
incremental  paths  for  addition  of  these  autonomy  options  to  the  DSCS  III 
spacecraft.  Each  path  in  Figure  7-2  could  potentially  lead  to  achieving 


♦Category  !  functions  are  those  which  must  be  autonomous.  Class  C  functions 
require  extensive  additions  to  the  existing  DSCS  III  spacecraft. 


31 


Level  5  DSCS  III 


Level  5  autonomy,  but  the  steps  would  be  different  from  path  to  path.  Since  no 
system-level  design  work  has  been  performed,  the  paths  to  full  autonomy  shown 
in  Figure  7-2  are  only  a  subset  of  those  possible.  In  fact,  some  of  the  steps 
along  the  paths  may  be  unfeasible  or  undesirable.  However,  the  example  paths 
are  discussed  to  illuminate  issues  which  design  and  implementation  of  an 
autonomous  DSCS  III  will  have  to  face.  The  design  implications  of  the  path 
selection  will  be  significant  even  if  the  steps  are  more-or-less  functionally 
constant.  It  is  emphasized  that  the  design  examples  developed  for  the 
assessment  are  only  conceptual  and  are  in  no  way  exhaustive  of  the  design 
possibilities. 


In  order  to  provide  some  feeling  for  the  scope  of  potential 
impacts  on  DSCS  III  of  increasing  autonomy,  some  bounds  on  mass  and  power 
impacts  have  been  estimated.  It  must  he  emphasized  that  many  secondary 
mass/power  impacts  cannot  be  identified  without  a  system  design  effort, 
aUhough  they  may  be  as  large  as  the  primary  impacts.  “Secondary"  impacts  are 
those  changes  to  the  spacecraft  which  would  result  from  incorporation  of  the 
autonomous  features.  For  example,  the  existing  spacecraft  volume  or  available 
attachment  area  may  be  inadeguate  for  the  computer  additions,  or  the  fields  of 
view  may  be  inadequate  for  the  autonomous  navigation  sensors,  requiring 
structural  modification.  Table  7-3  summarizes  the  range  of  estimates.  In 
Table  7-3  examples  of  the  function  to  be  made  autonomous  by  each  step  are 
listed,  roughly  in  order  of  increasing  difficulty,  corresponding  to  the 
minimum-to-maximum  capability  progression  possible  in  each  step. 


Table  7-3.  Summary  of  Range  of  Estimates 


STEP 

— 

EXAMPLES  OF  FUNCTIONS 

impacts 

MASS 

AVERAGE  POWER  ’ 

MINIMUM 

MAXIMUM 

MINIMUM 

MAXIMUM 

REPROGRAM  ACS 

•  MACRO  COMMAND  BLOCKS 

•  OPTIMIZED  PARAMETERS  AND  CONTROL  LAWS 
FROM  FLIGHT  EXPERIENCE 

•  INVALID  EARTH  LOSS  SIGNAL  FILTER 

NOt 

'IE 

0 

9.5  W 

ADD  TO  ACS 

•  REDUNDANCY  management  OF  ACS 

•  FULL  AUTONOMY  OF  ACS  EXCEPT  FOR 
A4ANEUVERS 

TBD 

»512  WORDS' 

TBD 

<18k  V.ORDS) 

2.6  W 

i512  WORDS' 

-  65  W 

I'Bk  'WORDS' 

ADO  RMS 

•  REDUNDANCY  MANAGEMENI  OE  TliC  PEUS 
SELECTED  SPACECRAFT  FUNCTIONS 

•  REDUNDANCY  MANAGEMENI  OF  ALL  S.'C 

•  REDUNDANCY  MANAGEMENI  PLUS  SERVICE 

AND  RESOURCE  MANAGEMENT  FUNCTIONS 

(8k  WORDS) 

6  Lg 
(INC 

NV  STORAGE) 

{32k  WORDS) 

12  kg 

(INC 

NV  STORAGE) 

(8k  WORDS' 

B  'W 

(  INC 

NV  STORAGE) 

(32k  WORDS' 

12  w 
(INC 

NV  STORAGE' 

ADD  NONVOLATILE  STORAGE 

•  AUDIT  TRAIL 

•  PROGRAM  SrORACt 

•  AUTONOMOUS  STATIONKEEPING  DATA 

STORAGE 

(10*  bi!$l 

(BUBBLE) 

UO’  biti! 

18  kg 

(TAPE' 

no*  bitii 

2  w 

'BUBBLE' 

_ 1 

iio’bl-s' 

3  V. 

iTAPl  ' 

ADD  DPU» 

•  SUBSYSTEM  FAULT  DETECTION  AND 

CORRECTION 

15 

(5  REDUNDANT  0 

Us  AT  3  kg  EACH) 

10 

1  5  REDUNDANT  Of 

Us  AT  :  [ACF' 

ADD  AUTO.  NAV.  SENSORS 

•  ATTITUDE  CONTROL  FUNCTIONS 

•  INCREASED  FLEXIBILITY  |N  GROUND  - 
DIRECTED  MANEUVERS 

•  AUTONOMOUS  NAVIGATION  ENABLED 

20  kg 

55  kg 

90 

ADDAUW.  NAV.  COMPUTER 

•  AUTONOMOUS  NAVIGATION 

*  (NCfttASeO  AUTO.  NAV,  ACCURACY 

I6L .  16  bi'i 

6  kg 

32k,  32  L-i's 

10  kg 

_ 1 

'6k  ,  '6  t-.‘s 

3 

_ 

32k,  32  i  -s 

ADD  TELECOMMUNI¬ 
CATION  AUTONOMY 

SEE  TABLE  7-4 

0 

30  kg 

0 

NOU;  UNLESS  OTHtRWISE  SPECIFIED,  V^ORDS  ARE  8  E.lt,  IN  lINGIIl 


33 


Estimates  for  the  attitude  control  subsystem  (ACS)  microcomputer 
additions  are  based  on  available  literature  on  the  LSIll  computer.  This  was 
inadequate  to  evaluate  potential  mass  impacts.  Estimates  for  the  autonomous 
navigation  sensors  are  also  based  on  available  literature. 

Mass/power  estimates  for  all  other  computer  additions  are  based 
on  the  design  assumptions  for  the  redundancy  management  subsystem  (RMS)  (see 
Section  4. 1.1. 2  of  Volume  III).  This  design  utilizes  Galileo  technology  and 
techniques.  Estimates  for  other  mass/power  impacts  are  based  on  JPL  design 
experience  and  rules  of  thumb. 

The  following  paragraphs  describe  the  steps,  the  implications  of 
their  implementation,  and  the  preliminary  estimates  of  their  mass  and  power 
requi rements. 

7.2.1  Reprogram  ACS  Computer  (Software  Changes  Only) 

As  discussed  in  Section  2.2.4  of  Volume  III,  the  existing  ACS 
microcomputer  may  be  capable  of  being  reprogrammed  to  deal  with  a  limited 
number  of  functions  autonomously.  Two  modes  for  reprogramming  are  possible: 
in  flight  and  prelaunch.  The  existing  ACS  microcomputer  has  redundant  RAMs 
with  1000  16-bit  words  each,  which  can  be  reprogrammed  in  flight  by  the  RAM 
patch  mode,  or  before  launch.  Additional  autonomous  features  would  compete 
with  other  functions  currently  in  the  RAM,  which  has  a  total  capacity  to 
approximately  contain  the  Voyager  ACS  fault  routines  (  1000  words)  described 
in  Section  1.3  of  Volume  III.  As  long  as  the  RAMs  remain  redundant, 
therefore,  the  ACS  will  have  less  fault  protection  capability  than  Voyager's 
ACS.  If  the  standby  RAM  were  allowed  to  be  used  for  fault  protection 
routines,  the  ACS  could  possibly  be  brought  to  about  the  same  level  of 
autonomy  as  the  Voyager  ACS.  However,  it  should  be  noted  that  the  Voyager 
computer  command  subsystem  (CCS)  provided  executive  control  and  fault 
protection  for  the  ACS  computer  on  Voyager.  No  CCS  equivalent  is  available  in 
the  exi sting  PSCS  III. 

The  ACS  computer  has  redundant  8k  ROMs.  All  available  ROM  space 
is  now  used,  but  only  about  half  of  this  is  for  the  attitude  control  programs. 
The  remainder  is  used  by  the  executive  routines  and  the  payload  beam  forming 
network  (BFN)  program.  The  basic  ACS  programs  also  utilize  only  about  half  of 
the  CPU  computational  cycle  time,  with  the  BFN  program  taking  the  remainder 
(when  the  BFN  program  runs).  It  appears  that  the  CPU  can  handle  about  twice 
the  ACS  load  if  strategies  and  priorities  for  handling  BFN  and  autonomy 
improvements  are  established.  For  example,  flexible  interleaving  of  health 
checks  and  fault  detection  and  analysis  for  redundancy  switching  could  be 
accomplished  at  multiples  of  basic  computational  frame  time.  BFN  execution 
should  also  be  adaptable  within  a  few  frames,  since  it  is  not  a  dynamic,  real¬ 
time  issue. 

The  ACS  currently  has  no  control  access  to  manage  redundant  ACS 
blocks  for  fault  recovery. 


7.?. 1.1  In-Flight  Reprogramming.  Options  for  reprogramming  the  ACS 
computer  after  launch  appear  to  be  very  limited.  JPL's  experience  is  that 
after  in-flight  experience  with  a  system  is  gained,  the  on-board  computers  can 
often  be  reprogrammed  to  remove  excessive  conservatism  caused  by  lack  of 
familiarity  with  how  the  spacecraft  would  really  operate  in  flight.  An 
example  is  the  opening  of  attitude  control  autopilot  tolerances  in  the  fault 
protection  algorithms  on  Voyager,  and  the  use  of  both  CCSs  on  Viking  and 
Voyager  to  serve  the  sequence  function,  rather  than  holding  one  in  standby 
reserve. 


Some  options  for  reprogramming  may  become  feasible  in  HSCS  III 
with  more  in-flight  experience,  but  will  most  likely  be  limited  to  the  type  of 
changes  already  anticipated  to  be  introduced  by  the  existing  RAM  patch  mode. 
These  include  changes  to  existing  routines  to  change  program  code,  work  around 
degraded  ROM,  and  allow  simple  enable/disable  of  autonomous  functions.  More 
information  on  the  existing  computer  is  needed  to  evaluate  the  possibilities 
for  in-flight  reprogramming,  but  they  are  likely  to  be  very  limited  because  of 
the  computer's  characteristics.  RAM  patching  could  provide  a  13%  increase  in 
available  memory,  and  uses  the  redundant  RAM  while  the  prime  RAM  is  active. 


7. 2. 1.2  Prelaunch  Reprogramming.  After  the  first  one  or  two  DSCS  Ills 

are  flown,  the  experience  gained  may  allow  changes  in  the  ACS  computer 
software  to  increase  the  spacecraft  autonomy.  Such  a  situation  occurred  when 
experience  gained  during  the  Viking  prime  mission  allowed  the  extended  prime 
mission  to  be  conducted  more  autonomously.  Even  if  this  is  the  case,  the 
present  ACS  computer  appears  fairly  full  with  its  current  autonomous  attitude 
control  software.  It  is  likely  that  only  a  few,  simple  autonomous  functions 
could  be  added,  unless  the  standby  RAM  could  be  programmed  independently. 

Candidate  functions  for  increasing  autonomy  would  be  those  which 
currently  send  the  spacecraft  into  a  survival  mode,  greatly  reducing  its 
operational  capabilities  while  a  situation  is  analyzed.  Two  examples  of  this 
are  the  loss  of  earth  presence  signal  (Section  4. 3. 2. 2  of  Volume  11)  and  the 
battery  discharge  80-minute  timer  (Section  4. 2. 3. 2. 2  of  Volume  II).  In  both 
cases  the  spacecraft  turns  off  nonessential  loads  (including  the  payload 
functions),  turns  on  the  S-band  telemetry  alert  to  ground,  and  remains  in  this 
survival  mode  until  instructed  to  change  by  the  ground.  In  both  cases  modes 
of  triggering  the  survival  mode  can  be  envisioned  for  which  the  survival 
response  is  excessive.  Certainly,  if  autonomy  is  to  be  introduced,  an  early 
requirement  would  be  to  eliminate  loss  of  the  payload  function  unless  the 
circumstances  are  severe  enough  to  warrant  it. 

Some  relatively  simple  tests  for  the  cause  and/or  severity  of 
the  situation  could  be  introduced  so  that  the  survival  mode  would  only  be 
entered  when  necessary.  For  example,  battery  discharge  rate  could  be  measured 
instead  of  battery  charge  time,  and  loads  shed  only  when  necessary.  This 
would  require  a  replacement  of  the  80-minute  timer  with  a  battery  discharge 
indication  and  adding  hardware  interfaces  and  software  to  the  ACS  to  determine 
an  acceptable  discharge  level. 
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Another  example  is  to  cross-check  the  earth  presence  signal  loss 
with  the  earth  sensor  readings  and  attitude  states  .iust  prior  to  the  "loss" 
signal.  This  would  identify  whether  the  earth  presence  signal  indicators  were 
at  fault  rather  than  the  spacecraft  being  turned  away  from  the  earth.  The 
incorporation  of  logic  to  enable  earth  reacquisition  if  the  spacecraft  were 
turned  away  might  also  be  feasible.  The  primary  driver  on  the  computer 
requirement  for  automating  this  is  the  extent  to  which  fault  isolation  and 
correction  (what  caused  the  turn?)  and  reacquisition  verification  are  felt  to 
be  needed. 


The  above  examples  have  not  been  designed  in  this  assessment 
phase  and  are  used  only  for  specifying  the  type  of  functions  which  might  be 
candidates  for  prelaunch  reprogramming.  It  is  unlikely  that  very  extensive 
additional  autonomy  can  be  added  without  some  level  of  hardware  change  (e.g., 
replacing  the  80-minute  timer). 

If  the  CPU  capacity  of  the  existing  ACS  computer  were  fully 
utilized,  the  computer  would  require  about  twice  as  much  power  on  the  average  as 
its  current  consumption.  As  stated  in  Section  4.3.6  of  Volume  III,  average 
power  use  could  increase  by  9.5  W.  In-flight  reprogramming  via  the  RAM  patch 
will  require  power,  but  this  is  already  designed  into  the  system. 


7.2.2  Add  to  ACS  Computer  (Hardware/Software) 


7. 2. 2.1  Addition  of  RAM  or  ROM  Modules  to  ACS.  As  mentioned  in  Section 

2.2.4  of  Volume  III,  the  minimum  addition  to  the  ACS  RAM  or  ROM  would  be  51? 
words.  Possibly  one  or  two  such  additions  would  provide  enough  capability  to 
provide  autonomy  for  the  functions  which  currently  result  in  a  spacecraft 
survival  mode,  as  discussed  in  the  preceding  section.  Additional  ROM  could  be 
used  for  providing  more  flexibility  in  the  ACS  service  functions.  For  example, 
blocks  of  commands  now  sent  from  the  ground  could  be  stored  in  the  ACS, 
requiring  only  a  single  ENABLE  command  from  the  ground  for  the  spacecraft  to 
implement  the  entire  block.  This  would  save  ground  time  and  uplink  time,  and 
reduce  the  probability  of  command  and  decoding  error. 

Some  ACS  redundancy  management  functions  could  be  introduced,  but 
these  would  require  hardware  modification  for  new  inputs  and  outputs  to  provide 
access  to  the  ACS  direct  current  (DC)  relay  matrix,  electric  power  distribution 
subsystem  (EPOS)  DC  relays,  or  the  TTfiC  command  decoder  as  described  in  Section 

4.3.5  of  Volume  III. 


7.2,2.?  Maximum  Addition  to  ACS.  Section  4.3.5  of  Volume  III  qives  an 

upper  limit  of  18k  vyords  (nonredundant)  additional  RAM  or  ROM  space  for  the  ACS 
microcomputer.  In  comparison  with  the  approximately  1000  words  used  for 
attitude  control  fault  protection  on  Voyager  plus  another  1000  words  for  CCS 
autonomy,  this  would  appear  ample  for  ACS  services  and  integrity  maintenance,  as 
well  as  additional  spacecraft  functions.  An  initial  assessment  of  the  OSCS  III 
attitude  control  ground  software  has  identified  at  least  seven  points  of 
comparison  with  the  Voyager  attitude  control  flight  software.  These  points  of 
comparison  are  for  fault  detection  and  recovery  functions  and  are  described  in 
Section  4.3  of  Volume  III.  The  assessment  shows  that  the  Voyager  and  DSCS  III 
attitude  control  function  fault  protection  algorithms  have  some  similarity. 

This  implies  that  the  OSCS  III  ground  algorithms  will  be  useful  in  designing 
Voyager-type  fault  protection  for  the  ACS,  and  that  the  ACS  upgrade  path  will 
allow  on-board  ACS  integrity  maintenance  to  be  performed.  One  example  of  a 
thruster  firing  fault  protection  algorithm  was  developed  for  DSCS  III  during  the 
assessment.  The  routine  would  comprise  about  75  words  and  be  executed  within  1 
to  1.5  ms  with  the  current  CPU  on  OSCS  III.  With  the  addition  of  sufficient 
input/output  (I/O),  memory,  and  interface  lines,  the  ACS  could  manage  its  own 
redundancy.  A  capability  for  the  ACS  computer  to  conduct  self-test  and 
redundancy  swaps  could  be  added  by  providing  ports  to  monitor  the  CPU  heartbeat. 
A  RAM  refresh  monitor  of  the  CPU  could  be  implemented  by  a  read/write  comparison 
between  accumulator  and  memory  location. 

If  the  maximum  ACS  addition  were  made,  redundancy  would  be  required; 
therefore,  the  total  impact  could  be  as  much  as  32k  words  of  memory. 

Information  on  commercial  equivalents  of  the  LSlll  gives  power  requirements  for 
4k  of  16-bit  ROM  as  14  W  averaqe/20.5  W  maximum.  Of  this  total  the  first 
512-word  ROM  module  added  would  require  2.63  W,  with  remaining  ROM  nodules 
requiring  1.63  W,  each. 

No  mass  information  on  the  LSlll  RAM  or  ROM  addition  was 
available.  Estimates  of  the  mass  impact  of  increasing  the  ACS  capacity  are 
therefore  not  included.  It  should  be  noted  that  the  remaining  computer 
mass/power  estimates  for  the  RMS  and  autonomous  navigation  computers  assume 
modern,  low  mass/power,  complementary  metal  oxide  semiconductor  (CMOS)  computer 
technology.  Therefore,  the  ACS  additions  are  expected  to  be  considerably  higher 
in  terms  of  mass  and  power  than  the  RMS  and  autonomous  navigation  computers 
discussed  below.  One  issue  in  adding  large  amounts  of  additional  RAM  or  ROM  to 
the  ACS  computer  is  the  age  of  the  computer.  This  technology  has  been 
superseded  since  1975  in  terms  of  low  mass  and  power,  and  parts  may  be  difficult 
to  procure. 


7. 2. 2. 3  Other  ACS  Modifications  for  Enhanced  Autonomy.  The  capability  for 

an  "all -axes  inertial"  mode  of  operation  can  benefit  the  autonomy  of  the 
attitude  control  function.  This  would  require  adding  pitch  and  roll  rate  gyros, 
as  a  minimum.  For  maximum  benefit  (to  provide  autonomous  recovery  from  3-axis 
dynamic  problems),  precision,  rate-integrating  gyros  should  be  added  to  all 
three  axes.  Gyros  would  also  provide  an  independent  path  to  verify  attitude 
state  estimation  based  on  optical  sensors.  In  addition,  they  would  allow  the 
performance  of  mutual  calibration/drift  correction  and  fault  diagnosis  with  the 
optical  sensors,  without  the  spacecraft  survival  mode  being  necessary. 
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7. 2. 2. 4  ACS  Upgrade  vs.  RMS.  Addinq  to  the  ACS  computer  may  be  the 

least  expensive  way  to  add  autonomy  for  additional  ACS  service  functions  and 
some  spacecraft  system  functions,  such  as  the  survival  modes.  In  order  for  the 
ACS  to  handle  spacecraft-level  redundancy  management  in  addition  to  its  own  ACS 
redundancy  control,  duplication  of  I/O  devices  between  the  ACS  and  the  TTFtC 
would  probably  be  necessary.  To  provide  new  inputs  will  require  adding  ports 
which  function  in  a  similar  fashion  as  the  existing  sensor  port.  This  port(s) 
would  process  both  analog  and  bi-level  digital  signals.  Output  access  could  be 
provided  to  both  the  ACS  and  EPOS  by  adding  a  new  port  to  drive  the  ACS  resident 
OC  relay  matrix  as  the  TT&C  command  decoder  now  does,  but  in  a  shared  mode  with 
the  TT&C.  This  could  also  be  used  to  issue  EPOS  DC  commands. 

At  some  point  the  cost  of  adding  many  I/O  devices  will  exceed  the 
cost  of  adding  a  new  computer  to  connect  with  the  existing  TT&C  I/Os. 

Therefore,  trade-offs  must  be  made  to  determine  this  point.  This  trade  will 
determine  whether  the  mixed  strategy  path  should  be  followed,  or  whether  either 
the  ACS  upgrade  or  RMS  path  is  preferable. 

In  upgrading  the  ACS  computer,  trades  will  be  necessary  between 
adding  ROM  or  RAM.  RAM  is  programmable  in  flight,  but  is  vulnerable  to 
radiation  effects  and  a  power  off/on.  ROM  can  only  be  programmed  before  launch 
but  is  not  susceptible  to  radiation  and  power  on/off.  The  JPL  experience  is 
that  the  flexibility  for  reprogramming  to  revise  or  add  autonomous  capabilities 
in  flight  is  very  important,  this  can  allow  for  (1)  increasing  autonomy  as  more 
confidence  is  gained  in  the  system,  (2)  correcting  autonomy  algorithms  for  flaws 
which  can  only  be  discovered  in  flight,  or  (3)  compensating  for  degradations  in 
the  satellite  system  (such  as  spares  depletion). 

Since  it  appears  that  expansion  to  include  full  spacecraft 
redundancy  management  and  autonomous  navigation  is  beyond  the  expansion 
capability  of  the  ACS,  at  least  one  other  spacecraft  computer  will  be  needed. 


7.2.3  Add  Redundancy  Management  Subsystem 

The  most  straightforward  way  of  making  the  DSCS  III  satellite 
system  maintain  its  own  integrity  is  to  provide  an  on-board  system  for  managing 
the  spacecraft's  redundancy.  The  addition  of  a  redundancy  management  subsystem 
for  integrity  maintenance  of  the  TT&C  subsystem  is  described  in  Section  4.5  of 
Volume  III.  Such  a  subsystem  would  have  access  to  telemetry  data  from  the  whole 
spacecraft  and  could  therefore  be  used  for  management  of  redundancy  throughout 
the  spacecraft.  The  RMS  includes  nonvolatile  storage. 


7. 2. 3.1  Minimum  Option.  The  preliminary  design  work  done  during  the 

assessment  sized  the  mi nimum  RMS  at  6  kg  and  8  W  of  power.  This  could 
undoubtedly  handle  redundancy  management  for  the  TTXC  subsystem.  Some  spacecraft 
redundancy  management  could  also  be  performed.  The  easiest  type  of  fault 
correction  (that  is,  where  the  solution  to  a  fault  is  to  switch  units)  could  be 
implemented  first,  but  faults  would  probably  not  be  isolated.  Some  crucial 
or  time-critical  switching  decisions  for  the  spacecraft  could  also  be  made. 

Since  the  RMS  has  access  to  the  command  stream,  it  is  in  a  position  to  function 
as  an  executive  computer,  much  as  the  CCS  on  Voyager  and  Viking.  With  8k  words 
of  read/write  memory  devoted  to  fault  protection  functions  (compared  with  1000 


to  2000  words  on  Viking  and  Voyager),  substantial  fault  protection  should  be 
possible.  The  extent  to  which  the  minimum  redundancy  management  function  could 
handle  fault  correction  would  depend  on  the  capability  required  to  analyze  and 
isolate  faults.  The  RMS  could  also  handle  autonomous  responses  to  the  survival 
mode  situations  discussed  in  the  ACS  upgrade  options. 


7. 2. 3. 2  Maximum  Option.  The  RMS  could  increase  in  size  and  capability 

as  described  in  Section  4.1 .1  of  Volume  111.  The  maximum  practical  memory  size 
for  an  RMS  alone  (no  distributed  processing  units)  appears  to  be  about  32k 
words.  Verification  of  this  limit  requires  a  much  more  comprehensive  design 
effort.  Interactions  with  the  ACS  computer  must  also  be  addressed.  The  maximum 
RMS  is  estimated  to  weigh  12  kg  and  require  12  W  of  power. 

As  a  test  of  whether  the  ground  algorithms  for  integrity 
maintenance  of  the  current  DSCS  Ill  would  be  applicable  to  on-board  redundancy 
management,  a  battery  high-temperature-recovery  algorithm  was  programmed  for  the 
RMS.  The  RMS  design  appears  to  lend  itself  to  having  this  typical  algorithm 
on-board,  at  a  cost  of  361  8-bit  words.  The  algorithm  is  described  in  Volume 
III,  Section  4.1.3. 


7.2.4  Add  Long-Term  Storage 

Section  4. 1.1. 3. 2  of  Volume  III  estimates  that  10^  bits  of  storage 
would  be  required  for  the  RMS  to  store  fault  protection  diagnostic  data  and 
audit  trails  for  60  days.  This  estimate  was  not,  of  course,  based  on  a  system 
design  effort.  Nonvolatile  storage  will  also  be  required  for  storing  routine 
maintenance  and  service  function  audit  trails.  For  functions  such  as  hydrazine 
resource  management,  much  longer-term  data  storage  than  60  days  may  be  required 
to  do  trend  analysis  for  slowly  varying  conditions.  Storage  of  extensive 
software  programs  that  can  be  accessed  by  the  RMS  for  reloading  volatile 
memories  throughout  the  spacecraft  will  be  required.  If  the  ACS  upgrade  path  is 
taken,  nonvolatile  storage  will  have  to  be  introduced.  If  the  RMS  path  is  taken 
nonvolatile  mass  storage  will  still  need  to  be  added. 

When  the  autonomous  navigation  function  is  added,  even  more 
long-term  storage  will  be  required  for  such  things  as  star  maps,  ephemerides  of 
the  sun  and  moon,  and  environmental  model  constants. 

Long-term,  nonvolatile  storage  required  for  full  autonomy  may 
therefore  require  capacities  up  to  10^  bits.  Design  decisions  will  be  necessary 
to  determine  the  best  way  of  adding  such  storage.  For  example,  up  to  10^  bits, 
bubble  memory  is  probably  the  best  technology  to  use.  For  10^  to  lo"  bits, 
magnetic  tape  is  superior.  It  may  be  more  efficient  to  add  a  tape  storage 
capability  in  excess  of  immediate  need  to  allow  for  future  expansion.  The 
storage  must  be  radiation  hardened. 

The  RMS  mass  and  power  estimates  include  nonvolatile  storage.  To 
add  nonvolatile,  bubble  memory  storage  to  the  ACS  upgrade  path  would  require 
between  10®  and  10^  bits  for  a  modest  number  of  functions.  Estimates  made  using 
Galileo  technology  are  1.5  kg  and  2  to  8  W  of  power  for  10®  bits  of  bubble 
memory  and  a  lOOk-bit/second  data  rate.  The  2  W  number  assumes  standby 
operation,  and  the  8  W  estimate  is  for  active  operation.  Increasing  the 
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capability  to  10^  bits  will  increase  the  power  requirements  to  3  W  and  16  W, 
respectively.  The  mass  requirement  for  a  10^-bit  memory  is  estimated 
to  be  3  kq. 

For  mass  storaqe  (10^  to  10^^  bits)  a  magnetic  tape  recorder 
system  has  been  sized.  The  sizing  is  based  on  the  Galileo  tape  recorder 
subsystem,  and  assumes  redundant  recorders  with  9  x  10®  bits  of  storaqe 
capacity  each  (one  active,  one  in  standby).  The  technology  is  radiation 
hardened.  Mass  for  this  design  is  estimated  to  be  IR  kg.  An  average  power  of 
3  W  is  required.  During  certain  brief  periods,  peak  power  of  20  W  may  be 
required,  but  the  impact  of  this  peak  load  on  the  power  subsystem  is  estimated 
to  be  negligible. 


7.2.5  Add  Distributed  Processing 

Expanded  redundancy  management  capability  can  be  realized  by 
adding  distributed  processing  units  (OPUs)  as  described  in  Section  4.1.2  of 
Volume  III.  Strategies  for  incorporating  the  DPUs  depend  on  whether  previous 
steps  expanded  the  ACS  computer  functions  to  include  redundancy  management. 

Use  of  a  maximum  option  RMS  design  in  conjunction  with  DPUs 
should  provide  the  capacity  for  redundancy  management  of  the  ACS  and 
autonomous  navigation  functions  as  well  as  those  of  other  spacecraft 
functions. 


In  the  final  Level  5  spacecraft  there  are  likely  to  be  as  many  as 
five  major  functions  requiring  DPUs.  Before  the  addition  of  autonomous 
navigation,  these  could  be  Power,  Attitude  Control,  Thermal  Control, 
Telecommunication,  and  Propulsion,  The  payload  is  also  likely  to  have  its  own 
autonomy.  The  RMS  could  manage  payload  redundancy  with  the  addition  of  a  DPU 
and  control  links.  But,  because  this  study  did  not  assess  payload  autonomy,  the 
potential  payload  DPU  is  not  considered  further. 

When  autonomous  navigation  is  added,  the  propulsion  DPU  could  be 
shifted  to  the  autonomous  navigation  function  because  this  will  handle  most 
autonomous  propulsion  functions,  as  described  in  Section  4.6  of  Volume  III. 

As  described  in  Section  4.1  of  Volume  III,  redundant  DPUs  are 
estimated  to  weigh  3  kg  and  require  2  W  of  power,  each.  Thus,  five  redundant 
DPUs  are  estimated  to  weigh  15  kg  and  require  about  10  W  of  power. 


7.2.6  Add  New  Sensors  for  Attitude  Control  and  Autonomous  Navigation 

Sensors  which  could  allow  orbital  position  determination  could  be 
added  to  the  spacecraft  and  used  for  attitude  control  before  the  full  autonomous 
navigation  capability  is  installed.  This  would  require  significant  changes  in 
the  ACS  interface  ports  and  logic.  A  side  benefit  of  installation  of 
sophisticated  sensors  would  be  that  the  restrictions  would  be  eliminated  which 
forbid  maneuvers  near  noon  and  midnight  because  of  the  current  sun  sensor 
system.  This  would  add  operational  flexibility  to  the  ground  maneuver  system. 
Some  very  approximate  estimates  of  mass  and  power  requirements  have  been  made 
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for  three  examples  of  possible  navigation  sensors;  space  sextant,  muUimission 
attitude  determination  and  autonomous  navigation  (MADAN),  and  a  British 
autonomous  stationkeeping  system  (ASKS). 

Such  sensors  could  be  added  at  a  number  of  points  in  the  flow  of 
autonomy  additions.  The  time  frame  will  be  determined  largely  by  the 
availability  of  technology.  Revision  of  the  ACS  interfaces  and  logic  to 
utilize  these  sensors  is  linked  to  their  addition.  With  the  new  attitude 
control /autonomous  navigation  sensors  added,  the  existing  sun  and  earth  sensors 
can  be  deleted,  saving  approximately  3.2  kg  and  3.5  W.  Structural  implications, 
particularly  with  respect  to  fields  of  view,  have  not  been  addressed. 

The  system  components,  description  of  assumptions,  and 
appropriate  values  are  given  for  each  example  in  the  following  paragraphs. 


7.2.6. 1  Space  Sextant.  Preliminary  space  sextant  estimates  for  an 

operational  system  were  obtained  from  two  briefing  chart  sets  (Reference  3). 
The  minimum  mass  case  is  for  a  single  space  sextant  aboard  the  spacecraft  at 
minimum  mass.  The  maximum  mass  is  for  a  two-space-sextant,  redundant  set  at 
maximum  mass.  Power  figures  assume  only  one  unit  operational  with  any  other 
powered  down.  (It  is  not  clear  whether  these  are  peak  or  average  power 
figures.) 

20  kg  <  mass  <  56  kg 

45  W  <  power  <  60  W 


7. 2. 6. 2  MADAN  Sensor  Package.  A  potential  MADAN  (Reference  4) 

configuration  is  one  of  three  star  sensors  and  one  earth  sensor,  with  one  star 
sensor  inactive.  Mass  power  figures  for  this  configuration  are  a  maximum  of  the 
baseline  MADAN  sensor,  and  a  minimum  for  a  lower-performance,  strategic 
satellite  (STRATSAT)  version.  These  give: 

20  kg  <  mass  <  31  kg 

70  W  <  power  <  90  W 


7. 2. 6. 3  Autonomous  Stationkeeping  (ASKS).  The  configuration  was 

developed  for  the  European  Space  Research  Organization  (ESRO)  and  is  documented 
in  a  British  report  (Reference  5).  The  sensor  setup  basically  consists  of  a 
Polaris  sensor,  sun  sensors,  and  an  earth  sensor.  The  configuration  here 
consists  of  the  on-board  DSCS  III  earth  sensors,  and  6  ADCOLE  sun  sensors,  two 
active  at  a  time.  The  figures  represent  minimum  weight,  as  no  mounting,  sun 
shade,  or  interface  connection  weights  are  included,  with  specific  values 
obtained  from  Reference  6. 


22  kg  3=  mass 
24  W  5K  power 
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7.2.7 


Add  Autonomous  Navipation  Computer 


Computer  sizinq  for  the  autonomous  navigation  function  will  be 
performed  as  part  of  the  autonomous  PSCS  III  design  phase.  Some  very  rough 
estimates  of  computer  characteristics  have  been  extrapolated  from  the  British 
ASKS  configuration,  including  sufficient  margin  for  fault  detection/protection 
and  growth.  In  terms  of  word  length  and  memory  requirements  these  are: 

16  bits  <  word  length  <  32  bits 

16k  words  T  memory  size  T  32k  words 

Floating-point  arithmetic  capability  is  required  for  maximum  efficiency  of  the 
design,  coding,  maintenance,  and  operation  of  navigation  algorithms. 

In  any  event,  introduction  of  this  large  navigation  computer  to 
the  system  containing  an  expanded  ACS  computer  or  a  large  RMS  computer,  or 
both,  will  require  executive-level  decisions.  Trade-offs  will  have  to  be  made 
between  having  functions  carried  out  at  the  lowest  possible  level  for 
simplicity  and  reliability,  and  having  a  higher-level  executive  in  control. 

An  example  is  hydrazine  tank  selection.  The  RMS  function  affects  tank 
selection  in  failure  cases.  The  ACS  places  requirements  on  tank  selection  for 
center-of-mass  control.  The  Navigation  function  influences  tank  selection 
through  maneuver  size  and  frequency  requirements.  A  careful  design  trade-off 
is  necessary  to  provide  executive  control  of  tank  selection  in  a  manner  that 
satisfies  the  requirements  of  all  these  subsystems  while  minimizing  the 
chances  of  conflict  in  control  authority. 

Since  the  RMS  has  access  to  the  spacecraft  command  system,  it 
may  be  in  the  best  position  to  provide  the  executive  function.  The  option 
also  exists  to  combine  the  RMS,  ACS,  and  Navigation  functions  in  a  single 
computer  facility.  At  least  one  internally  fault-tolerant  computer  is  needed 
to  maintain  the  integrity  of  the  other  computers.  The  RMS  design  includes 
internal  fault  tolerance. 

A  very  rough  estimate  was  made,  using  the  RMS  technology 
mass/power  ranges,  for  the  computer  requirements  given  above.  The  RMS  uses  an 
8-bit  word.  It  was  assumed  that  16-  and  32-bit  words  could  be  created  by 
adding  8-bit  word  processors.  Therefore,  a  16k  16-bit  machine  was  assumed 
equal  to  a  32k  8-bit  machine.  This  would  require  one  Galileo  subchassis 
which  would  weigh  about  3  kg,  and  would  consume  about  3  W  of  power. 

Additional  memory  could  be  added  for  about  '>  kq/2  W  to  bring  the  processor  to 
128k  8  bits,  or  the  equivalent  of  a  32k  32  oit  processor.  Therefore,  the 
upper  limit  of  the  range  for  an  autonomouf  navigation  computer  should  be  about 
6  kg  and  5  W  total.  Redundant  autonomous  lavigation  computers  will  be 
necessary  plus  executive  control  by  a  fau  t-tolerant  computer.  Therefore,  the 
total  impact  will  be  10  kg  and  5  W  for  th  larger  two  computers,  or  6  kg/3  W 
for  the  smaller  computers,  with  one  compu  er  powered  at  a  time. 
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7.2.8 


Autonomous  Options  for  Telecommunication  Functions 


Volume  III  describes  options  for  adding  autonomy  to  the 
Telecommunications  functions.  Sections  4.1.3  and  4.5.3  of  Volume  III  describe 
autonomous  options  for  the  Telemetry  function.  Section  4.5.4  of  Volume  III 
discusses  autonomy  options  for  the  Command  functions.  Section  4.7.1  of  Volume 
III  presents  options  for  increasing  the  autonomy  of  the  Tracking  function. 

Table  7-4  summarizes  the  mass  and  power  estimates  for  these 
telecommunication  autonomy  options.  Some  of  the  autonomy  options  rely  on  an 
RMS,  others  are  independent.  In  any  event,  selection  of  telecommunication 
autonomy  options  is  independent  of  other  autonomy  options  which  might  be 
chosen.  Telecommunication  is  only  required  for  the  60-day /6-month  requirement 
for  unattended  spacecraft  operation  to  be  met  because  of  a  requirement  for  an 
X-band  TT&C  downlink  for  payload  user  tracking,  timing,  and  telemetry.  These 
functions  could  be  retained  by  providing  telecommunication  autonomy,  or  by 
providing  a  direct,  X-band  downlink  to  payload  control  for  payload  functions. 
The  latter  option  will  impact  payload  control  ground  operations.  However, 
meeting  other  autonomy  goals  in  Reference  2  would  require  telecommunication 
capability,  viz,  both  telemetry  for  audit  trails,  and  command  for  ground 
executive  control  of  autonomous  functions. 


Table  7-4.  Telecommunication  Function  Autonomy  Options  -- 
Rough  Mass  and  Power  Estimates 


I. 


OPTION 

POWER, 

w 

COMMENT 

VOL.  Ill 
REFERENCE 

MAINTAIN  TELEMETRY 

A,  CN/CPF  SEQUENCER 

0.5 

A  1.3 

B.  RF  POWER  MONITOR 

C.  TELEMETRY  FAILURE 

0.5 

NO  CHANGE  WITH  RMS 

4,5.3.  I 

SENSING 

— 

PART  OF  RMS 

4. 5. 3. 2 

D,  DIRECT  FAILURE  SENSING 

6  TO  12 

10  TO  20 

4, 5. 3, 3 

MAINTAIN  COMMAND 

A.  USE  AS  IS 

B  .  S-BAND  COMMON  FREQUEN- 

0 

0 

4.5.4.  1 

CIES 

0.3 

0.3 

4  5.4.2 

C.  X-BAND  DUAL  CARRIER 

0.5 

20 

BOTH  COMMUNICATION  SUB¬ 
SYSTEM  FREQUENC  ;  STAN¬ 
DARDS  ON  AND  BOTH  DE- 
CRYPTERS  ON 

4. 5.4.3 

D.  TELEMETRY  FAILURE 

SENSING 

— 

___ 

PART  OF  RMS 

4  .  .  4  .  i 

E.  DIRECT  FAILURE  SENSING 

F.  CYCLIC  COMMAND  "NOT 

5  TO  10 

8  TO  16 

4  .  S  .  4 . 5 

TO  SWITCH" 

MAINTAIN  TRACKING 

A.  XMT  RCV  FUNCTIONS 

I.O 

1.0 

SAME  AS  1  AND  II  ABOVE 

4. 5.4,6 

4.  1.3, 4. 5. 3. 
4.5.4 

B  .  LEAVE  RANGING  ON 

0.0 

0.0 

NORMAL  OPERATIONAL  MODE 

4.7.1  .1 

C.  RANGING  ON  CYCLIC 

0.5 

0.5 

4.7.1.,/ 

D.  S-BAND  STABLE  OSCILLATOR 

E.  S-BAND  STABLE  OSCILLATOR 

6.0 

12.0 

4.7.1  .5 
4.7.  1 .6 

USE  SHF  OSCILLATOR 

0.5 

0.5 

SYNTHESIZE  FROM  COMMUNI¬ 
CATION  SUBSYSTEM  REFERENCE 

NOTE:  ALL  ESTIMATES  ARE  ROUGH  AND  INTENDED  ONLY  TO  GIVE  AN  APPROXIMATE 
MASS  AND  POWER  RANGE. 
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The  options  listed  in  Table  7-4  are  roughly  in  order  of 
increasing  difficulty,  and  increasing  mass/power  impact.  Specific  paragraphs 
in  Volume  III  which  refer  to  each  option  are  referenced.  Note  that  the  on-off 
seguencer  is  a  precursor  addition  for  many  of  the  other  autonomous  functions, 
but  that  the  other  additions  are  relatively  independent.  '  ^ 

7.2.9  Relation  of  Autonomy  Options  to  Current  DSCS  III  Design 

Figure  6-2  (see  Section  6.1.2)  is  a  subsystem  level,  block 
diagram  of  the  existing  DSCS  III  design.  Existing  block  and  functional 
redundancies  are  shown,  as  are  links  between  subsystems.  Figures  7-3(a)  and 
7-3(b)  illustrate  an  example  of  how  one  option  to  create  a  Level  5  autonomous 
spacecraft  could  be  added  to  the  existing  design.  Figures  7-3(a)  and  (b) 
correspond  to  Path  3  of  Figure  7-2  (the  mixed  strategy).  Paths  1  and  2  of 
Figure  7-2  can  be  similarly  related  to  the  existing  DSCS  III  block  diagram. 

Other  options  are  possible,  of  course,  including  those  where 
subsystem  boundaries  are  redefined  or  whole  subsystems  are  replaced.  For 
example,  in  Path  2  the  RMS  might  be  designed  to  completely  replace  the  ACS  and 
autonomous  navigation  computers,  resulting  in  a  combined  central  computing 
subsystem.  The  diagrams  shown  in  Figures  7-3(a)  and  (b)  are  merely  to  put  the 
autonomous  options  in  a  DSCS  III  subsystem  perspective.  Actual  implementation 
of  autonomy  will  be  addressed  in  the  forthcoming  design  task. 

In  Figure  7-3(a)  the  first  five  steps  of  Figure  7-2  are  shown  as 
they  might  be  added  to  the  existing  DSCS  attitude  control  and  TT&C 
subsystems.  Up  to  18k  words  of  redundant  ROM  or  RAM  could  be  added  to  the  ACS 
computer.  (Other  possible  additions  such  as  gyros  are  possible,  but  are  not 
illustrated  here.)  The  RMS  could  be  added  to  Interface  only  with  the  TT&C, 
and  the  DPUs  and  nonvolatile  storage  would  interface  with  the  existing  TT3C 
system  through  the  RMS. 

Figure  7-3(b)  illustrates  how  the  further  addition  of  the 
autonomous  navigation  function  could  be  accomplished.  New  attitude 
control/autonomous  navigation  sensors  replace  the  existing  attitude  control 
sensors  and  interface  both  with  the  (possibly  upgraded)  ACS  and  with  the  new 
autonomous  navigation  computer.  An  interface  between  the  propulsion  system 
and  the  autonomous  navigation  computer  is  also  added.  The  RMS  is  revised  to 
function  in  an  additional  capacity  as  an  executive  for  the  autonomous 
navigation  computer.  Additional  control  and  data  lines  could  be  added  to  let 
the  RMS  function  as  an  executive  for  the  ACS  computer,  as  well. 
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Figure  7-3b.  Example  of  Mixed  Strategy  Path  Additions  to  the  Existing 
DSCS  III  System:  Last  Two  Steps 


7.3 


SUMMARY  OF  MASS/POWER/COMPLEXITY  IMPACT  PRELIMINARY  ESTIMATES 


In  addition  to  the  obvious  impacts  of  autonomy  on  spacecraft 
mass  and  power,  there  are  impacts  on  the  desiqn  in  terms  of  complexity.  The 
Level  5  autonomous  spacecraft  may  have  up  to  10  active  computer  processors 
on  board  containing  up  to  2x10^  bits  of  information.  In  addition, 
nonvolatile  data  storage  of  up  to  10^  bits  may  be  required.  The  hardware 
design  of  these  computing  elements  appears  relatively  straiahtfo'ward,  and 
potential  hardware  solutions  are  described  in  Volume  111.  However,  JPL 
experience  (and  the  general  experience  of  computer  users)  has  shown  that  the 
design,  validation,  and  operation  of  systems  which  include  large  amounts  of 
computing  capability  is  a  challenging  problem. 

Section  7.3.1  discusses  estimates  of  the  mass/power  impacts  of 
autonomy.  Section  7.3.2  discusses  estimates  of  the  complexity  impacts  of 
autonomy. 


7.3.1  Spacecraft  Autonomy  Mass/Power  Impacts 

In  order  to  provide  a  range  of  possible  impacts  of  implementing 
Level  5  autonomy,  the  mass  and  power  estimates  of  implementing  the  RMS  path 
(Path  2  of  Figure  7-2)  have  been  summarized  in  Figures  7-4  and  7-5.  These 
figures  illustrate  the  range  of  impacts  attendant  on  adding  the  RMS  to  the 
long-term  storage,  the  DPlIs,  the  autonomous  navigation  sensors,  and  the 
autonomous  navigation  computer,  in  steps.  The  top  line  represents  the  maximum 
total  mass/power  added  by  each  step,  the  bottom  line  represents  the  minimum. 
The  figures  show  that  redundancy  management  may  be  accomplished  with  "modest 
impact,"  but  autonomous  stationkeeping  is  likely  to  require  "extensive" 
modification.  The  figures  show  a  range  of  55  to  131  kg  and  47  to  127  W,  for 
the  fully  autonomous  spacecraft  additions,  excluding  health  and  welfare 
state  sensors,  propulsion  impacts,  and  spacecraft  structural  changes  which 
might  be  necessary  to  implement  the  autonomy  features. 

The  lower  end  of  the  mass  and  power  impact  range  would  be  a 
more-or-less  "modest"  impact  to  the  nSCS  III  satellite,  while  the  upper  end  of 
the  range  would  mean  "extensive"  impacts  (up  to  15%  of  mass).  However,  mass 
additions  of  as  much  as  50%  are  planned  in  future  PSCS  III  block  procurements, 
where  the  spacecraft  dry  mass  is  planned  to  be  as  much  as  1200  kg  for  a 
satellite  incorporating  autonomous  fault  protection  and  stationkeeping. 


Since  mass/power  estimates  on  the  ACS  microcomputer  are 
unavailable,  a  summary  of  the  "ACS  upgrade"  path  cannot  be  provided.  The 
impacts  will  likely  be  higher  than  the  RMS  path  because: 

(1)  The  computer  technology  is  older  and  more  mass  and  power 
intensive,  and 

(2)  Additional  I/O  devices  and  connectors  are  required  to 
duplicate  existing  TTf«C  control  links. 

Impacts  of  any  desired  telecommunication  autonomy  would  be  over  and  above 
those  summarized  in  Figures  7-4  and  7-5.  The  mass  estimates  in  Figure  7-4 
were  derived  by  adding  some  (power  and  cabling)  of  the  secondary  mass  impacts, 
described  in  the  following  paragraphs,  to  the  mass  estimates  from  Table  7-3. 

The  additional  power  requirements  of  the  autonomous  functions 
will  require  increased  power  from  the  OSCS  III  power  subsystem.  Some  rough 
rules  of  thumb  have  been  used  to  estimate  the  mass  impact  of  these  power 
increases.  No  attempt  was  made  to  deal  with  power  profiles  in  making  these 
estimates.  The  total  additional  mass  required  is  about  0.13  to  0.15  kg/W  of 
additional  power  required.  Power  requirements  were  taken  from  Table  7-3.  The 
mass  range  is  based  on  current  and  near-future  technology  for  solar  panels, 
and  on  nickel-cadmium  batteries. 

Additional  connectors  and  cabling  will  be  required  to  implement 
the  autonomous  functions.  These  could  add  considerable  mass  to  the 
spacecraft.  However,  this  is  dependent  on: 

(1)  The  number  of  connections. 

(2)  The  routing  strategies. 

(3)  The  connector/cable  materials. 

Rule-of-thumb  estimates  of  the  mass  impacts  of  cabling  and 
connectors  result  in  an  increase  in  the  mass  of  autonomy  options  of  5  to  10%. 

Significant  increases  in  spacecraft  mass  will  increase  the 
propellant  requirements  for  attitude  control  and  maneuvers.  This  will  either 
result  in  a  shorter  on-orbit  life,  or  will  require  a  larger  propulsion  system 
with,  in  turn,  increased  overall  spacecraft  mass.  Propulsion  impacts  have  not 
been  estimated. 

The  estimates  of  mass  and  power  do  not  include  potential  added 
spacecraft  state  sensors  which  may  be  required  to  implement  the  autonomous 
features.  Therefore,  the  estimates  assume  that  the  existing  telemetry  data 
are  adequate  for  on-board  autonomy  computations.  Future  design  efforts  may 
reveal  the  need  for  additional  state  sensors,  vdiich  would  add  an  unknown,  but 
probably  small  amount  of  mass  and  power  requirements. 

Adding  the  autonomous  components  to  the  spacecraft  will  require 
that  they  be  attached  to  the  spacecraft  structure.  The  impact  of  structural 
fasteners,  brackets,  or  changes  to  the  structure  itself  has  not  been 
included. 
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gure  7-4.  Preliminary,  Estimated  Mass  Impacts  of  Autonomous  Additions, 
Excluding  Structure,  Propulsion,  and  State  Sensors 


127  W  -  14.1% 


Addition  of  features  for  the  autonomy  of  the  Telecommunications 
functions  will  depend  on  how  the  TTAC  functions  of  Command,  Telemetry , and 
Tracking  are  utilized  when  the  spacecraft  is  made  autonomous.  Some  of  the 
telecommunication  autonomy  options  in  each  category  (telemetry,  command, 
tracking)  shown  in  Table  7-4  can  be  added  together.  For  example,  the  on/off 
seguencer  and  radio  freguency  (RF)  power  monitors  in  the  telemetry  options 
could  be  added  separately  or  in  combination.  However,  options  designated  as 
d,  e,  or  f  are  probably  best  implemented  singly.  Thus,  telecommunication 
autonomy  impacts  can  be  added,  as  desired,  to  the  mass  and  power  estimates  in 
Figure  7-4  and  7-5. 


Telecommunication  autonomy  can  be  implemented  at  a  cost  of  0.3 
to  35  kg  in  mass,  and  0.3  to  52  W  of  power,  excluding  structure  and 
propulsion  impacts. 

7.3.2  Spacecraft  Autonomy  Complexity  Impacts 

Complexity  is  difficult  to  express  in  simple  terms.  Figure  7-6 
presents  two  measurements;  (1)  the  number  of  active  computer  processors  and 
(2)  bits  of  information  contained  on  board  in  the  active  processors.  Figure 
7-6  differs  from  Figure  7-4  and  7-5  in  that  the  mixed  strategy  (Path  3  in 
Figure  7-2)  is  displayed  in  Figure  7-6.  This  shows  the  cumulative  effect  if 
the  ACS  were  upgraded  and  the  RMS,  DPlIs,  and  the  autonomous  navigation 
computers  were  added  to  create  a  Level  5  spacecraft.  This  path  could  result 
in  as  many  as  10  active  processors  being  on  board.  These  processors  could 
contain  between  704k  and  2032k  bits  of  information  in  active  memory.  An 
additional  10^  to  10^  bits  could  be  required  for  nonvolatile  storage. 

JPL's  Viking,  Voyager,  and  Galileo  experience  and  the  HSAF 
Defense  Meteorological  Satellite  Program  (DMSP)  experience  are  included  in 
Figure  7-6  for  reference.  This  illustrates  that,  in  terms  of  total  active 
processing  complexity,  the  Level  5  autonomous  spacecraft  would  be  somewhere 
betweeen  Voyager  (349k  bits  in  4  active  processors)  and  Galileo  (1984k  bits  in 
18  active  processors).  About  20%  of  this  capacity  is  devoted  to  fault 
protection  on  the  JPL  spacecraft.  The  remainder  of  the  capacity  is  for 
sequences  to  provide  services  to  the  payload  of  science  instruments.  JPL  is 
currently  developing  the  Galileo  spacecraft  and  support  system,  and  has 
discovered  that  the  task  of  designing  and  validating  a  computer  system  of  this 
complexity  is  formidable.  It  is  expected  that  systems  design  and  validation 
of  a  Level  5  autonomous  spacecraft  may  be  equivalent.  For  USAF  projects,’  a 
major  advantage  will  be  realized  when  the  investment  associated  with  this 
process  can  be  amortized  over  a  class  of  similar  defense  satellites. 
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Figure  7-6.  Prel i mi na ry ,  Estimated  Impacts  of  Complexity  Expressed  in  Number  of 
Active  Computer  Processors  and  Bits  of  Information 
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APPENDIX  A 


LEVELS  OF  AUTONOMY 

(Reproduced  directly  from  Reference  1) 


In  performance  of  a  space  mission,  four  major  policy  goal  categories 
have  been  identified.  These  are: 

(1)  Ground  interaction  reduction. 

(2)  Spacecraft  integrity  maintenance. 

(3)  Autonomous  features  transparency. 

(4)  On-board  resource  management. 


The  extent  to  which  these  goals  have  been  accomplished  to  date  has  been 
through  a  mix  of  functions  resident  in  either  the  space  segment  or  the 
ground  segment.  Furthermore,  the  ground  segment,  as  an  integral  part  of  the 
total  system,  has  been  responsible  for  accomplishing  maintenance,  navigation 
mission  control,  and  payload  d’ta  orocessing.  Thus,  only  minimal  spacecraft 
autonomy  has  been  needed. 

The  levels  of  autonomy  described  in  this  appendix  are  used  to  define  a 
step-wise  increase  in  spacecraft  autonomous  capability.  By  proceeding 
through  the  levels,  autonomous  capability  is  increased  in  the  space  segment 
and  dependency  on  the  ground  segment  is  reduced. 

The  levels  of  autonomy  are  described  as  follows: 

level  0.  A  design  without  redundant  elements  which  meets  all  mission 
needs  by  operating  without  the  on-board  control  of  state  parameters  (such  as 
rates  and  position).  May  respond  to  a  prespecified  vocabulary  of  external 
commands,  but  cannot  store  command  sequences  for  future  time-or  event- 
dependent  execution  or  validate  external  commands.  (An  open-loop,  on-board 
system  controlled  from  the  ground.) 

Level  1.  Includes  Level  0  but  uses  on-board  devices  to  sense  and 
control  state  parameters  (such  as  rates  and  positions)  in  order  to  meet 
performance  needs.  Is  capable  of  storing  and  executing  a  prespecified 
command  sequence  based  on  mission-critical  time  tags.  Will  respond  to 
prespecified  external  commands,  but  cannot  validate  external  commands. 
Functionally  redundant  modes  may  be  available  for  a  degraded-performance 
mi ssion. 

Level  2.  Include  Level  1  plus  the  use  of  block  redundancy.  Ground- 
controlled  switching  of  spare  resources  is  required.  Uses  cross-strapping 
techniques  to  minimize  effect  of  critical  command  link  (uplink)  failure 
modes.  Significant  ground-operator  interaction  is  required  to  restore 
operations  after  most  faults  if  spare  spacecraft  resources  are  available. 
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Requires  operator  interaction  for  fault  recovery.  Is  capable  of  storing  and 
executing  mission-critical  events  vrtiich  are  sensed  on-board  and  may  be 
independent  of  time. 

Level  3.  Includes  Level  2  and  is  capable  of  sensing  prespecified 
mission-critical  fault  conditions  and  performing  predefined  self-preserving 
(entering  a  safe-hold  state)  switching  actions.  Is  capable  of  storing 
contingency  or  redundant  software  programs  and  being  restored  to  normal 
performance  (maintaining  the  command  link  with  a  single  link  fault)  in  the 
event  of  a  failure.  Timers  may  be  used  to  protect  resources.  Requires 
ground  operator  interaction  for  fault  recovery.  In  general,  the  failure  to 
sense  and/or  execute  the  mission-critical  event(s)  will  cause  mission 
failure  or  loss  of  a  major  mission  objective. 

Level  4.  Includes  Level  3  but  is  also  capable  of  executing 
prespecified  and  stored  command  sequences  based  on  timing  and/or  sensing  of 
mission  events,  firound-initiated  changes  to  command  sequences  may  be 
checked  on-board  for  syntactical  errors  (parity,  sign,  logic,  time).  Uses 
coding  or  other  self-checking  techniques  to  minimize  the  effects  of 
internally  generated  data  contamination  for  prespecified  data  transfers. 
Requires  ground-operator  interaction  for  fault  recovery.  In  general, 
failure  to  sense  and/or  execute  the  mission  event(s)  or  state-changes 
(excluding  failure-induced  state-changes)  will  cause  mission  failure  or  loss 
of  a  major  mission  objective. 

Level  5.  Includes  Level  4  and  is  also  autonomously  fault-tolerant.  Is 
capable  of  operating  in  the  presence  of  faults  specified  a-priori  by 
employing  spare  system  resources,  if  available,  or  will  maximize  mission 
performance  based  upon  available  capability  and/or  available  expendables 
(i.e.,  self-loading  of  contingency  programs)  without  ground  intervention. 

Level  6.  Includes  Level  5  and  is  capable  of  functional  commanding  with 
on-board  command-sequence  generation  and  validation  prior  to  execution. 
Functional  commanding  may  include  a  high-level,  pseudo-English  language, 
spacecraft-system/operator  communication  and  control  capability. 

Level  7.  Includes  Level  6  and  is  capable  of  autonomously  responding  to 
a  changing  external  environment,  defined  a-priori,  so  as  to  preserve  mission 
capability.  The  capability  to  change  orbit  in  order  to  compensate  for 
degradation  or  to  protect  the  satellite  from  an  external  threat  is 
included. 

Level  8.  Includes  Level  7  and  is  capable  of  operating  successfully 
within  the  presence  of  latent  design  errors  which  could  cause  loss  of  major 
mission  objectives. 

Level  9.  Includes  Level  8  and  is  capable  of  task  deduction  and 
i nternaV  reorganization  based  upon  anticipated  changes  in. the  external 
environment.  This  situation  is  exemplified  by  multiple  satellites  operating 
in  a  cooperative  mode.  In  the  event  of  a  satellite  failure,  remaining 
satellites  would  detect  autonomously  the  condition  (task  deduction)  and  may 
generate  and  execute  orbit-and  spacecraft-reconfiguration  commands. 
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Level  10.  Includes  Level  9  and  is  capable  of  internal  reorganization 
and  dynamic  task  deduction  based  on  unspecified  and  unknown/unanticipated 
changes  in  external  environment.  The  system  will  strive  to  maximize  system 
utility.  Thus,  mission  objectives  should  be  adaptive  and  automatically 
reprogrammable.  System  resources  should  be  maximized  to  preserve  task 
adaptiveness. 
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APPENDIX  B 


CLASSIFICATION  DEFINITIONS 


Levels  of  Autonomy:  An  arbitrarily  defined  scale,  ranginq  from  "0"  to 
"10",  is  used  to  define  a  stepwise  increase  in  spacecraft  autonomous 
capability.  These  levels  are  defined  in  Appendix  A. 

Function  Categories:  Three  categories  are  defined  for  spacecraft 
f  un  ctions : 


(1)  Provide  services  to  payload. 

(2)  Manage  spacecraft  resources. 

(3)  Maintain  integrity  of  spacecraft. 

See  Section  6.1.2  for  a  more  complete  discussion  of  functional  categories. 

Functional  Classes  of  Activities;  Within  each  functional  category, 
defined  above,  three  classes  of  activity  are  necessary: 

(1)  Sense  (or  perceive  a  need). 

(2)  Direct  (and  control  an  action  plan). 

(3)  Act  (execute  the  plan). 

Table  6-1,  Section  6.1.2,  relates  the  function  categories  to  the  class  of 
activities,  and  the  related  discussion  on  Page  20  and  21  expands  upon  these 
definitions. 

Prioritization  Categories;  Not  all  spacecraft  functions  need  be  made 
autonomous  in  order  for  the  spacecraft  to  meet  its  predefined  goals. 

Functions  were  therefore  prioritized  into  three  categories  of  importance: 

(1)  Category  I:  Functions  which  must  be  performed  autonomously 
for  the  spacecraft  to  meet  the  60-day/6-month  requirement. 

(2)  Category  II:  Functions  which  must  be  performed 
autonomously  for  lifetime  protection  (battery  conditioning, 
etc.)  or  which,  if  performed  autonomously,  would  increase 
the  operability  or  operational  flexibility  of  the 
spacecraft. 

(3)  Category  III:  Functions  not  requiring  autonomy. 

Section  6. 1.3. 2  discusses  the  basis  for  the  categories. 
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Implementation  Difficulty:  It  is  recognized  that  it  will  be  more 
difficult  to  implement  some  autonomous  functions  than  others.  Classes  of 
difficulty  are  defined  as  follows: 

Class  A  =  Software  changes  only 
Class  B  =  Modest  additions 
Class  C  =  Extensive  additions 
Class  D  =  Redesign 

Section  6. 1.3. 3  amplifies  these  definitions. 
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